Re^4: redirect output from a command to another command

A lot of questions here...

"The reason given by the source is..."

Source of what?

It seems to me that picking a (somewhat) arbitrary number to use as a file descriptor, and then dup'ing to that descriptor is a bit risky. How can one be sure that it is not already in use by another process?

I also don't understand the close on exec thing. We've opened a filehandle which holds the output of the echo command. Do filehandles change descriptor numbers midstream somewhere? If it is closing on exec, does that mean it is closing after the echo command has finished executing? If that were true, then it wouldn't do any good to "keep open" after it has already closed.

If the user is already using fd3, then why would it get assigned to the echo command output?

I'm not disputing what you are saying, I just am not understanding why these things are. Your script seems to prove the close on exec thing. I guess one of the things I am wondering is "what exec"?

thanks, Allasso

Comment on Re^4: redirect output from a command to another command

Replies are listed 'Best First'.
Re^5: redirect output from a command to another command by ikegami (Patriarch) on Mar 02, 2011 at 17:03 UTC
Source of what? bash It seems to me that picking a (somewhat) arbitrary number to use as a file descriptor, and then dup'ing to that descriptor is a bit risky. How can one be sure that it is not already in use by another process? File descriptors are per process. You only have to make sure it's not used by the current process. I also don't understand the close on exec thing. Running a command in unix requires duplicating the current process using `fork` then calling `exec` to replace the program being run in the process. `system` is a wrapper around these. The close-on-exec flag determines whether the file handle will available after the exec or not. In a sense, whether the handle is inherited by the child process or not. fd 0, 1 and 2 must not be close-on-exec (or else the command won't have an open stdin, stdout and stderr) and the handle for `<()` must not be either. If the user is already using fd3, then why would it get assigned to the echo command output? Correcting myself, I think it's more that the user might later want to use fd 3. For example, `command <( command ) >&3` [download]	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^5: redirect output from a command to another command
by ikegami (Patriarch) on Mar 02, 2011 at 17:03 UTC

Source of what?

bash

It seems to me that picking a (somewhat) arbitrary number to use as a file descriptor, and then dup'ing to that descriptor is a bit risky. How can one be sure that it is not already in use by another process?

File descriptors are per process. You only have to make sure it's not used by the current process.

I also don't understand the close on exec thing.

Running a command in unix requires duplicating the current process using fork then calling exec to replace the program being run in the process. system is a wrapper around these.

The close-on-exec flag determines whether the file handle will available after the exec or not. In a sense, whether the handle is inherited by the child process or not. fd 0, 1 and 2 must not be close-on-exec (or else the command won't have an open stdin, stdout and stderr) and the handle for <() must not be either.

If the user is already using fd3, then why would it get assigned to the echo command output?

Correcting myself, I think it's more that the user might later want to use fd 3. For example,

command <( command ) >&3
[download]

[reply]
[d/l]
[select]