[Techtalk] Open file descriptors

[Dan Richter]

Since no one has answered this yet, I'll take a stab at it.

> Could somebody explain to me what an "open file descriptor" is, and
> how the execution of a program using '-r' is different from using
> '-c'?  How does the program "pass back commands to initlog"?

A file descriptor is simply a reference to an open file - or more 
generally, any stream of data. Another example of a stream of data is a 
socket connection (such as a file that's downloading over the Internet). 
But in this case, the "open file descriptor" is the stdout of the 
command that's executed by initlog.

(The fact that the file descriptor is "open" isn't particularly 
profound, because as soon as a file descriptor is "closed" it can't be 
read from or written to, and so is no longer good for anything.)

When you do this:
   ps -ef | grep inetd
the shell links the standard output of "ps" to the standard input of 
"grep". "grep" reads from standard input without worrying about where 
that input comes from. Behind the scenes, it reads from the file 
descriptor of stdin.

When you do this:
   initlog --run=foo
"initlog" spawns a thread that executes "foo". Now, when one program 
executes another, the parent program can read the child program's output 
(the parent program is listening on the other end of the child program's 
stdout). Normally you execute a program from a shell, so the shell 
receives the output and displays it. But in this case "initlog" is 
receiving the output from "foo".

Now, as for the difference between --cmd and --run, I've never used the 
program so I don't know. Presumably --cmd causes the command's output to 
simply be logged, whereas --run causes the program's output to somehow 
be interpreted as "what to do" by initlog.

-- 
    Presumably, we're all fully qualified computer nerds here,
    so we are allowed to use "access" as a verb. Be advised,
    however, that the practice in common usage drives
    English-language purists to scowling fidgets.
       - from Sybex's "Perl, CGI and JavaScript", p. 256