[Top][All Lists]

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

Re: fd leak with {fd}>

From: Sam Liddicott
Subject: Re: fd leak with {fd}>
Date: Mon, 26 Nov 2012 14:26:33 +0000

On Mon, Nov 26, 2012 at 1:49 PM, Pierre Gaston <address@hidden>wrote:

> On Mon, Nov 26, 2012 at 3:41 PM, Pierre Gaston <address@hidden>wrote:
>> On Mon, Nov 26, 2012 at 3:37 PM, Chet Ramey <address@hidden> 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
> It seems that ksh93 behaves just like bash in this regard....
> Well, as I don't use it I don't really care, but I vote for this as a bug
> as I fail to see the benefit of this behavior as i find it useless and not
> consistent with the normal redirection.

And also potentially renders the feature useless.

I had hours of debugging why my {fd} >( ... ) co-processes were not
terminating. A less tenacious user would give up on either {fd} or >( ... )
or both

For users to actually USE these features, the principle of least surprise
should be followed.

Ironically I was changing from my own method of allocating fd's (
http://blog.sam.liddicott.com/2012/03/local-variables-are-great.html) to
the simple "bash do it for me" and things broke because they didn't work
like anything similar in bash.

I would expect: exec {fd}>( ... }
to keep the descriptor open. if the user wants that he can do:
{ exec {fd}>... ; ... ; }
if he wants it to be closed when the scope ends he will do:
{ ... ; } {fd}>...

So I think this surprising behaviour adds nothing that wasn't there
already, and nothing that the user expects and also adds things that the
user will not expect


reply via email to

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