Re: {varname} redirection for a command or group leaves the file open

[Chet Ramey]

On 5/19/17 4:32 PM, tetsujin@scope-eye.net wrote:

>  > Well, that's disappointing. So there is no technical reason for
> this behavior 
>  > other than copying the behavior of ksh. BTW zsh does the right
> thing and in the 
>  > following scenario: 
>  > 
>  > ls -lh /proc/self/fd {fd}>/dev/null 
>  > 
>  > and it closes the file descriptor after the command has completed.

Face it: there's no real reason to implement this construct, period, and
especially little reason for the way the Korn shell does it.  A script
can trivially emulate the ksh usage by picking the file descriptor and
performing the variable assignment itself; this construct is minimal
syntactic sugar.

I think Korn introduced it to overcome the traditional sh restriction of
the user-modifiable file descriptors to the range 0-9. Bash doesn't have
that limitation, so that's not enough of a reason to do it.

The way bash implements it offers features that are not available in any
other use. While the not-closing aspects can be emulated using `exec', a
file descriptor manipulated with `exec' is close-on-exec. Bash offers a
direct analogue to the open system call.

Now, bash does implement some other constructs that are nothing but
syntactic sugar (|&), but only after user requests. There aren't any
user requests for this, so a purely syntactic sugar feature isn't any
direct user benefit. There needs to be something that isn't otherwise
available.

It's kind of flip to recommend not using it if you don't like it, but
that's pretty much the case here. Or accept the rationale and work
around it.

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/