On 6/30/21 11:49 AM, Joerg Schilling via austin-group-l at The Open Group
wrote:
Erm, yes. For some reason, I assumed the OP wrote &> instead of >&
which have the same meaning in GNU bash (but &> is the parse-trouble
one even if the bash manpage actively recommends it). I guess their
?~>&? confused me. My point of _please_ using ?>file 2>&1? instead
is still valid, ofc.
BTW: I would not call it a hard parse error but a semantic problem, since the
standard only mentions numbers after >&
It does not. The redirection is specified as `[n]>&word'. The standard
says:
"If word evaluates to one or more digits, the file descriptor denoted by n,
or standard output 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 a
file descriptor already open for output, a redirection error shall result;
see Consequences of Shell Errors. If word evaluates to '-', file descriptor
n, or standard output if n is not specified, is 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."
Everyone is conformant here. There is unspecified behavior.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU [email protected] http://tiswww.cwru.edu/~chet/
