On Wed, 23 Aug 2023, 12:20 Greg Wooledge, <g...@wooledge.org> wrote:
> > echo Hi {X}>/dev/null
> > ls -l "/proc/$$/fd/$X"
>
> That's a really strange example. I wonder what would lead someone to
> write that particular redirection.
Oh I merely wanted to point out that the redirection persists beyond the
echo command. It's basically the same as your example:
The thing I was testing was in response to this question, which was posed
> as an exercise:
>
> Swap stderr and stdout of a shell command.
>
> I gave […]
>
> cmd {fd}>&1 1>&2 2>&$fd {fd}>&-
>
> [which] does *not* close the temporary file
> descriptor
Well, it closes at as far as cmd is concerned, but not as far as the Shell
is concerned.
I would expect {fd}>&- to exactly undo {fd}>/path (or {fd}>&$otherfd), so
they should either both be local to the command, or both apply to the shell.
Indeed quite I'm perplexed as to why it wasn't designed this way to begin
with.
I'm also mystified as to why they persist, in stark contrast to other
redirections, but that's comparatively less important. (I recall there was
some discussion about the variable persisting, but I didn't think it
implied the fd itself would persist.)
This seems like a clear example of an experimental feature that should have
been indicated as such in the release notes, and only enabled when
explicitly chosen at build time (e.g. ./configure
--enable-all-experimental-features-without-warnings). Chopping and changing
behaviour in "permanent" releases creates a maintenance nightmare.
-Martin
