bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: fd leak with {fd}>


From: Chet Ramey
Subject: Re: fd leak with {fd}>
Date: Mon, 26 Nov 2012 11:57:33 -0500
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1

On 11/26/12 8:41 AM, Pierre Gaston wrote:
> 
> 
> On Mon, Nov 26, 2012 at 3:37 PM, Chet Ramey <chet.ramey@case.edu
> <mailto:chet.ramey@case.edu>> wrote:
> 
>     On 11/23/12 2:04 AM, Pierre Gaston wrote:
> 
>     > It seems rather counter intuitive that the fd is not closed after 
> leaving
>     > the block.
>     > With the normal redirection the fd is only available inside the block
>     >
>     > $ { : ;} 3>&1;echo bar >&3
>     > -bash: 3: Bad file descriptor
>     >
>     > if 3 is closed why should I expect {fd} to be still open?
> 
>     Because that's part of the reason to have {x}: so the user can handle the
>     disposition of the file descriptor himself.
> 
> . 
> I don't see any difference between 3> and {x}> except that the later free
> me from the hassle of avoid conflicting fd

That's not really an issue.  Bash goes to great effort to allow users to
specify fds it is already using internally.

The user/shell programmer getting a handle to the fd is one benefit.  The
ability to use those named fds in operators that don't allow words (e.g.
variable expansions) to replace the explicit file descriptor number is
another.

David Korn beat all of us in implementing this feature (we first began
discussing it in 2005).  I should ask him if he has additional insight.

Chet

-- 
``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/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]