If your web browser formats this page incorrectly, try viewing the
page source. In netscape 4, click the view menu, then click page source.

If you run a program, and redirect the output of the program to a pipe,
and no process is reading from the pipe; then the program will not run at
all until something reads from the pipe. ps will list the program as a
process, but apparently the kernel does not allocate any cpu time to the
program. If something starts to read from the pipe, then the program will
begin execution. If whatever is reading from the pipe closes the pipe before
the program is finished, the kernel will kill the program and a 'broken
pipe' error message will be displayed. I am not sure if the broken pipe
error message comes from the kernel or the program. If it comes from the
program, then probably different programs display different messages, and
some programs may display no message at all.

If you are piping the output of program1 to program2 with 'program1 |
program2', and if program1 is generating output very rapidly, and if
program2 is using input very slowly; then data will accumulate in the pipe.
If too much data accumulates in the pipe, then the kernel will stop
program1. In a simple test, my kernel stopped the first program when there
was about 10K in the pipe. Probably the kernel would restart the program
after the second program uses up the data in the pipe.

I am guessing here that the management of pipes is a kernel function; but
I could be wrong; it might be a bash function.
  User root can read, write, and delete any file and directory; root does
not need read or write priviledges; even if the permissions are set to
---------, where no one has read or write permission. In other words, root
always has read and write permission for every file, directory, device, etc.
root also has execute permission for every directory. Execute permission for
files owned by root depends on what the file permissions are set to. I did
not check execute permissions for files not owned by root, or execute
permissions for devices, pipes, etc.


  Programs running in the background are not supposed to generate output or
require input. If a program in the background writes to standard error, it
will be displayed, but it will probably mess up the display of the program
running in the foreground. If a program running in the background tries to
read from standard input, it will be stopped until you put it into the
foreground.