On 30/06/2021 16:56, Chet Ramey via austin-group-l at The Open Group wrote:
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'. [...]
mirabilos wrote that it was a misreading of >& as &>. For &>, it is a
different story:
echo hello &>/dev/null
In POSIX sh, this runs 'echo hello' in the background, and independent
of that, opens /dev/null for writing and immediately closes it, unless
this is explicitly made unspecified in some section I have missed. In
bash, even in POSIX mode, this runs 'echo hello' with both stdout and
stderr redirected to /dev/null.
Cheers,
Harald van Dijk
