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

[Peng Yu]

> 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 "-".

-- 
Regards,
Peng