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.