Pipelines and I/O Redirection

[gkl]

Dear All,

I am trying to understand the example used by tdlp.org for I/O Redirection in Unix. The example reads as follows (on the next line you can find my understanding of what is happening - could you please let me know if I am on the right track?):

exec 3>&1

In my understanding this sends any output to file descriptor 3 to file descriptor 1 (standard output).

ls -l 2>&1 >&3 3>&- | grep bad 3>&-

This would start off two processes and each will get the file descriptors open in the current shell. These, at the moment, are 0, 1, 2 and 3. The process on the left is redirecting standard error (file descriptor 2) to where standard output is going (file descriptor 1) and then standard output (along with standard error) to file descriptor 3. Then, file descriptor 3 is closed; would that not mean that standard output and standard error are closed as well as they point to the same location?

The process on the right is closing file descriptor 3; however, since its file descriptor 0 is linked to file descriptor 3 of the process on the left (after the redirections) would that not mean that it can not receive input at all? Why do we need to close the descriptor again?

exec 3>&-

Why is file descriptor 3 still open since we closed it in both sides of the pipeline in the previous statement?

Regards,
George

[Barry Margolin]

In article <ea976f3c-7eab-463a...@googlegroups.com>,

gkl <gkl...@gmail.com> wrote:

> Dear All,
>
> I am trying to understand the example used by tdlp.org for I/O Redirection in
> Unix. The example reads as follows (on the next line you can find my
> understanding of what is happening - could you please let me know if I am on
> the right track?):
>
> exec 3>&1
>
> In my understanding this sends any output to file descriptor 3 to file
> descriptor 1 (standard output).
>
> ls -l 2>&1 >&3 3>&- | grep bad 3>&-
>
> This would start off two processes and each will get the file descriptors
> open in the current shell. These, at the moment, are 0, 1, 2 and 3. The
> process on the left is redirecting standard error (file descriptor 2) to
> where standard output is going (file descriptor 1) and then standard output
> (along with standard error) to file descriptor 3. Then, file descriptor 3 is
> closed; would that not mean that standard output and standard error are
> closed as well as they point to the same location?

No. The stream and the descriptors that refer to them are independent.
The stream doesn't get closed until all descriptors that refer to it are
closed.

It's similar to the relationship between files and filenames. When you
do:

ln file1 file2

you create an additional name that refers to the file. If you then do:

rm file1

you can see access the file by the name file2. The file doesn't
actually disappear until all filenames are removed (also open streams to
it have to be closed).

>
> The process on the right is closing file descriptor 3; however, since its
> file descriptor 0 is linked to file descriptor 3 of the process on the left
> (after the redirections) would that not mean that it can not receive input at
> all? Why do we need to close the descriptor again?
>
> exec 3>&-
>
> Why is file descriptor 3 still open since we closed it in both sides of the
> pipeline in the previous statement?

Redirection of standard input/output in the pipeline doesn't affect the
original shell process, does it? So why would closing fd 3 in the
pipeline affect the original shell?

--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***