It's a pretty well-bugged program. It killed most of the processes I tried it on.
Well if you want to list file descriptors being used, taking bash
(1) as an example:
$ pidof bash0
$ ls /proc/4319/fd/
0 1 2 255
$ file /proc/4319/fd/*
/proc/4319/fd/0: symbolic link to `/dev/pts/0'
/proc/4319/fd/1: symbolic link to `/dev/pts/0'
/proc/4319/fd/2: symbolic link to `/dev/pts/0'
/proc/4319/fd/255: symbolic link to `/dev/pts/0'
are file descriptors (FD
) that represent their linked pseudo-terminal masters (PTM
is the standard input (stdin); 1
is the standard output (stdout), and 2
is the standard error (stderr), by convention.255
is returned to delimit the maximum file descriptors you can open, I think.
Or perhaps used not to collide with other ones (e.g., when sourcing). Or both.0
is a pseudo-terminal slave (PTS
) that's a pseudo-device with a text terminal interface, which is used
to communicate with device drivers (programs interacting with hardware devices) thanks to standard
input/output system calls which are processed by the kernel.
They are returned by the character file /dev/ptmx
when opened: the process bash
s which are each associated to PTM
s which are also associated to their
s created once the file descriptors are delivered to the process that ask for them.
If you want to intercept system calls, you can use strace
(1) per example.