It would be even nicer, if the standard mention in a sentence that this is explicitly meant to be usable for the purpose of differentiating between utility and redirection errors.

So I would support updating the standard to require that n<&n and n>&n are always a no-op if fd n is open, except that if the shell normally closes fds > 2, that were opened with exec, when it executes a non-built-in utility, then applying n<&n or n>&n to such commands causes fd n to remain open.

The standard does not exist for your personal benefit, so I do not think it should bless your highly specific use case.

However, it would make sense to briefly mention the closing-high-FDs behavior as motivation. Something along the lines of Geoff's wording in the thread would be more than sufficient:

2.7.5 Duplicating a File Descriptor

The redirection operators:

[n]<&word

and:

[n]>&word

shall duplicate one input file descriptor or output file descriptor, respectively, from another, or shall close one. If word evaluates to one or more digits, the file descriptor denoted by n, or standard input or standard output, respectively, if n is not specified, shall be made to be a copy of the file descriptor denoted by word; if the digits in word do not represent an already open file descriptor, a redirection error shall result (see Section 2.8.1); if the file descriptor denoted by word represents an open file descriptor that is not open for input or open for output, respectively, a redirection error may result. If word and n evaluate to the same open file descriptor, or if n is not specified and word evaluates to 0 or 1, respectively, no duplication shall occur; if the shell would have closed the file descriptor because it was opened using exec and has a value greater than 2, when the redirection is being performed in a command that will execute a non-built-in utility, the file descriptor shall instead remain open when the utility is executed. If word evaluates to '−', then file descriptor n, or standard input or standard output, respectively, if n is not specified, shall be closed. Attempts to close a file descriptor that is not open shall not constitute an error. If word evaluates to something else, the behavior is unspecified.

so what about things like <1 or >0 ?

As far as I understand the wording about the n = word case, wouldn't that also mean that e.g.:
   exec 8<some file; exec 8<8; utility
would now be expected to keep FD 8 open when invoking utility

exec 8<somefile; exec 8<&8; utility

if the shell would have closed the file descriptor because it was opened using exec and has a value greater than 2, when the redirection is being performed in a command that will execute a non-built-in utility, the file descriptor shall instead remain open when the utility is executed

What I at least would want to avoid is that people might ever come across this issue or the corresponding mailing list thread and assume that this is now the way to portably differentiate between utility non-zero exit status and redirection error, when wouldn't be really the case.

If it is a no-op then it can't fail. So the only possible failure case would be in the "remain open" requirement. In practice this will involve calling fcntl() to clear the FD_CLOEXEC flag, which could indeed fail because of something like resource exhaustion, but I don't see that it increases the likelihood of internal shell failure significantly. Any command execution can fail within the shell because of resource exhaustion (e.g. fork() failure) before it gets as far as doing the exec.

If you don't think it is, fine for me,... we can still make the change here, but should also mention that this cannot be expected to portably allow the above.

If you think it is and if you think that "briefly mentioning the closing-high-FDs behavior as motivation" is enough to also make sure that this is understood by any shell implementer, then I'm all good.

2.7.5 Duplicating a File Descriptor

The input redirection operator:

[n]<&word

and output redirection operator:

[n]>&word

shall duplicate one input file descriptor or output file descriptor, respectively, from another, or shall close one.

If word consists of one or more decimal digits which evaluate to a value not equal to n (or 0 or 1, respectively, if n is not specified), the file descriptor denoted by n (or standard input or standard output, respectively, if n is not specified) shall be made to be a copy of the file descriptor denoted by word. If the digits in word do not represent an already open file descriptor, a redirection error shall result (see [xref to 2.8.1]). If the file descriptor denoted by word represents an open file descriptor that is not open for input or open for output, respectively, a redirection error may result.

If word and n evaluate to the same open file descriptor, or if n is not specified and word evaluates to 0 or 1, respectively, no duplication shall occur. If the shell would have closed the file descriptor because it was opened using [xref to exec] and has a value greater than 2, when the redirection is being performed in a command that will execute a non-built-in utility the file descriptor shall instead remain open when the utility is executed.

If word evaluates to '-', then file descriptor n (or standard input or standard output, respectively, if n is not specified) shall be closed. Attempts to close a file descriptor that is not open shall not constitute an error.

If word evaluates to something else, the behavior is unspecified.

If, and only if, job control is disabled, the standard input for the subshell in which an asynchronous AND-OR list is executed shall initially be assigned to an open file description that behaves as if /dev/null had been opened for reading only. This initial assignment shall be overridden by any explicit redirection of standard input within the AND-OR list.

If, and only if, job control is disabled, the standard input for the subshell in which an asynchronous AND-OR list is executed shall be assigned to an open file description that behaves as if /dev/null had been opened for reading only, except that:

• This assignment shall not be performed if there is any explicit redirection of standard input, other than <tt><&0</tt> (or equivalent), within the AND-OR list.


• This assignment need not be performed if the AND-OR list is within a compound command and either there is any explicit redirection, other than <tt><&0</tt> (or equivalent), of the compound command's standard input or the compound command follows the control operator '|'.

Duplicating an Input File Descriptor

Duplicating a File Descriptor

If word and n evaluate to the same open file descriptor, the operation is a no-op except in shells which set the close-on-exec flag for file descriptors greater than 2 opened using [xref to exec]. In these shells, a redirection of this form can be used to clear the close-on-exec flag so that the file descriptor will remain open when executing a non-built-in utility. For example:

exec 3<infile 4>outfile
utility 3<&3 4>&4

One use for this feature, together with command and exec, is to differentiate between utility and redirection errors. For example:

( command exec 3<infile 4>outfile || exit 128; utility 3<&3 4>&4 )
case $? in
0)   # success
     ;;
128) # redirection error
     ...
     ;;
*)   # utility error
     ...
     ;;
esac

(This assumes utility is known not to use 128 as an exit status and that the shell does not detect an internal error such as resource exhaustion.)

Since the connection of the input to the equivalent of /dev/null is considered to occur before redirections, the following script would produce no output:

exec < /etc/passwd
cat <&0 &
wait

The assignment of standard input from an open file description that behaves like /dev/null is not overridden by an explicit <tt><&0</tt> redirection because this redirection does not perform a duplication and thus has no effect on where standard input comes from. This was the original Korn Shell behavior but was not clearly required by versions of this standard earlier than Issue 8 TC1, although in all those versions there was rationale stating that the following script would produce no output:

exec < /etc/passwd
cat <&0 &
wait

there_was_a_redirection_error=true
{
   there_was_a_redirection_error=false
   utility
} > this < that 2> redirection
if "$there_was_a_redirection_error"; then
  echo There was a redirection error and utility was not run
fi

If word evaluates to '-', then file descriptor n (or standard input or standard output, respectively, if n is not specified) shall be closed. Attempts to close a file descriptor that is not open shall not constitute an error. If a standard utility or a conforming application is executed with file descriptor 0 not open for reading or with file descriptor 1 or 2 not open for writing, the environment in which the utility or application is executed shall be deemed non-conforming, and consequently the utility or application might not behave as described in this standard.

Applications should not use the [n]<&- or [n]>&- operators to execute a utility or application with file descriptor 0 not open for reading or with file descriptor 1 or 2 not open for writing, as this might cause the executed program (or shell built-in) to misbehave.

2.7.5 Duplicating a File Descriptor

The input redirection operator:

[n]<&word

and output redirection operator:

[n]>&word

shall duplicate one input file descriptor or output file descriptor, respectively, from another, or shall close one.

If word consists of one or more decimal digits which evaluate to a value not equal to n (or 0 or 1, respectively, if n is not specified), the file descriptor denoted by n (or standard input or standard output, respectively, if n is not specified) shall be made to be a copy of the file descriptor denoted by word. If the digits in word do not represent an already open file descriptor, a redirection error shall result (see [xref to 2.8.1]). If the file descriptor denoted by word represents an open file descriptor that is not open for input or open for output, respectively, a redirection error may result.

If word evaluates to the same open file descriptor as n (or 0 or 1, respectively, if n is not specified), no duplication shall occur. If the shell would have closed the file descriptor because it was opened using [xref to exec] and has a value greater than 2, when the redirection is being performed in a command that will execute a non-built-in utility the file descriptor shall instead remain open when the utility is executed.

If word evaluates to '-', then file descriptor n (or standard input or standard output, respectively, if n is not specified) shall be closed. Attempts to close a file descriptor that is not open shall not constitute an error. If a standard utility or a conforming application is executed with file descriptor 0 not open for reading or with file descriptor 1 or 2 not open for writing, except for the case of an exec command with no operands that reopens one or more of those file descriptors, the environment in which the utility or application is executed shall be deemed non-conforming, and consequently the utility or application might not behave as described in this standard.

If word evaluates to something else, the behavior is unspecified.

If, and only if, job control is disabled, the standard input for the subshell in which an asynchronous AND-OR list is executed shall initially be assigned to an open file description that behaves as if /dev/null had been opened for reading only. This initial assignment shall be overridden by any explicit redirection of standard input within the AND-OR list.

If, and only if, job control is disabled, the standard input for the subshell in which an asynchronous AND-OR list is executed shall be assigned to an open file description that behaves as if /dev/null had been opened for reading only, except that:

• This assignment shall not be performed if there is any explicit redirection of standard input, other than <tt><&0</tt> (or equivalent), within the AND-OR list.


• This assignment need not be performed if the AND-OR list is within a compound command and either there is any explicit redirection, other than <tt><&0</tt> (or equivalent), of the compound command's standard input or the compound command follows the control operator '|'.

When a utility is executed with a redirection, for example:

utility < infile > outfile

it is generally not possible to tell from the exit status of the command whether a non-zero value is caused by failure of the utility or failure of the redirection. One method of differentiating the two is to apply the redirection to a compound command and include a command within the compound command that affects the current shell environment, such as setting a shell variable. For example:

redirection_error=true
{
     redirection_error=false
     utility
} < infile > outfile
if "$redirection_error"
then
    # There was a redirection error and utility was not run
    ...
fi

Duplicating an Input File Descriptor

Duplicating a File Descriptor

If word and n evaluate to the same open file descriptor, the operation is a no-op except in shells which set the close-on-exec flag for file descriptors greater than 2 opened using [xref to exec]. In these shells, a redirection of this form can be used to clear the close-on-exec flag so that the file descriptor will remain open when executing a non-built-in utility. For example:

exec 3<infile 4>outfile
utility 3<&3 4>&4

One use for this feature, together with command and exec, is an alternative method to the one described in [xref to C.2.7] of differentiating between utility and redirection errors. For example:

( command exec 3<infile 4>outfile || exit 128; utility 3<&3 4>&4 )
case $? in
0)   # success
     ;;
128) # redirection error
     ...
     ;;
*)   # utility error
     ...
     ;;
esac

(This assumes utility is known not to use 128 as an exit status and that the shell does not detect an internal error such as resource exhaustion.)

Since the connection of the input to the equivalent of /dev/null is considered to occur before redirections, the following script would produce no output:

exec < /etc/passwd
cat <&0 &
wait

The assignment of standard input from an open file description that behaves like /dev/null is not overridden by an explicit <tt><&0</tt> redirection because this redirection does not perform a duplication and thus has no effect on where standard input comes from. This was the original Korn Shell behavior but was not clearly required by versions of this standard earlier than Issue 8 TC1, although in all those versions there was rationale stating that the following script would produce no output:

exec < /etc/passwd
cat <&0 &
wait