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:
Code:
$ pidof bash
4358 4319
$ 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'
$
0,
1,
2 and
255 are file descriptors (
FD) that represent their linked pseudo-terminal masters (
PTM).
0 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 gets
independent
FDs which are each associated to
PTMs which are also associated to their
own
PTSs 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.
