[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Leak in BASH "named" file descriptors?
From: |
Chet Ramey |
Subject: |
Re: Leak in BASH "named" file descriptors? |
Date: |
Wed, 13 Apr 2016 14:08:27 -0400 |
User-agent: |
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 |
On 4/13/16 9:34 AM, Pierre Gaston wrote:
> For me the value is in 1) not hard coding the number and 2) being able to
> use more explicit names (eg "logfile" rather than "3"), nothing more.
If you limit the effects to those two, it's not a compelling feature to
add. In practice, the first is not a big problem if you're careful, and
the second can be trivially emulated with a single assignment statement.
> Of course if you use {var} for the redirections of an external command it's
> useless but not using a hard coded number can be useful if you use
> functions and don't want to have conflicts with someone else's function.
This is true, though bash does save and restore file descriptors where it
can if your hard-coded number is already in use.
> I don't really understand why using a symbolic name would need to provide
> more control, and in my opinion {var}> doesn't really provide something
> you can't do otherwise regarding the handling of the fd, it just has a
> different behavior.
It's an opportunity to provide more flexible behavior. The standard ways
to use file descriptors still exist, so if you don't like the different
behavior you have options.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU chet@case.edu http://cnswww.cns.cwru.edu/~chet/