[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 <pierre.gaston@gmail.com>wrote:
>
>
> On Mon, Nov 26, 2012 at 3:41 PM, Pierre Gaston <pierre.gaston@gmail.com>wrote:
>
>>
>>
>> On Mon, Nov 26, 2012 at 3:37 PM, Chet Ramey <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
>>
>
> 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
- fd leak with {fd}>, Sam Liddicott, 2012/11/16
- Re: fd leak with {fd}>, Chet Ramey, 2012/11/22
- Re: fd leak with {fd}>, Sam Liddicott, 2012/11/22
- Re: fd leak with {fd}>, Pierre Gaston, 2012/11/23
- Re: fd leak with {fd}>, Chet Ramey, 2012/11/26
- Re: fd leak with {fd}>, Pierre Gaston, 2012/11/26
- Re: fd leak with {fd}>, Pierre Gaston, 2012/11/26
- Re: fd leak with {fd}>,
Sam Liddicott <=
- Re: fd leak with {fd}>, Chet Ramey, 2012/11/26
- Re: fd leak with {fd}>, Sam Liddicott, 2012/11/26
- Re: fd leak with {fd}>, Chet Ramey, 2012/11/26
- Re: fd leak with {fd}>, Chris F.A. Johnson, 2012/11/26
- Re: fd leak with {fd}>, Dennis Williamson, 2012/11/26
- Re: fd leak with {fd}>, Chet Ramey, 2012/11/26
- Re: fd leak with {fd}>, Pierre Gaston, 2012/11/27
- Re: fd leak with {fd}>, Sam Liddicott, 2012/11/27
- Re: fd leak with {fd}>, Chet Ramey, 2012/11/26