bug-bash
[Top][All Lists]
Advanced

[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

Sam


reply via email to

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