Re: Do `>& -` and `<& -` also work?

[Andreas Kusalananda Kähäri]

On Mon, May 10, 2021 at 12:56:27PM -0500, Peng Yu wrote:
> > Yes, they work. You can confirm it for yourself by using the loadable
> > builtin `fdflags'
> 
> > or by using "ls -la /proc/$$/fd" if your system has
> > procfs.
> 
> OK. I didn't know this.
> 
> $ ls -ltr /dev/fd/42
> ls: cannot access '/dev/fd/42': Bad file descriptor
> $ exec 42<>/tmp/1.txt
> $ ls -ltrgR /dev/fd/42
> -rw-r--r-- 1 wheel 0 2021/05/10-10:36:16 /dev/fd/42
> $ exec 42>& -
> $ ls -ltr /dev/fd/42
> ls: cannot access '/dev/fd/42': Bad file descriptor
> 
> > > If they both work, is this made by design?
> >
> > Yes, I think so because it is explicitly mentioned in the manual (the
> > section I have quoted in
> > https://lists.gnu.org/archive/html/help-bash/2021-05/msg00005.html ).
> 
> The manual text that you quoted does not mention that there can be
> spaces after `&` in `[n]>&word`. So I wouldn't consider that this is
> clearly stated in the manual. As it is written, it doesn't seem to be
> by design. It looks more like it is a consequence of the
> implementation, which makes it just happens like that.
> 
> I would think lexer return `[n]>&-` as a whole may make more sense.
> Since `>&` has the meaning of dump stdout/err to a file, that file
> could be named as "-".
> 
> The current lexer returns ">&" and "-" separately, making people have
> to write `>& ./-` in order to write both stdout/err to a file named
> `-`. This seems to be a worse syntax overall than treating `>&-` as a
> whole, then `>& -` can just mean write stdout/err to the file "-".

Did you try your ">& ./-"?  I get

        $ echo hello >& ./-
        bash: ./: ambiguous redirect

What you want is probably ">- 2>&1" or "&>./-". This comes back to the
section of the manual where it says that out of "&>" and ">&", the first
one is preferred.  Personally, I would suggest using ">- 2>&1".


> 
> -- 
> Regards,
> Peng

-- 
Andreas (Kusalananda) Kähäri
SciLifeLab, NBIS, ICM
Uppsala University, Sweden

.