Re: fd leak with {fd}>

[Sam Liddicott]

On Tue, Nov 27, 2012 at 7:08 AM, Pierre Gaston <pierre.gaston@gmail.com>wrote:

>
>
> On Mon, Nov 26, 2012 at 10:48 PM, Chet Ramey <chet.ramey@case.edu> wrote:
>
>> On 11/26/12 12:11 PM, Sam Liddicott wrote:
>> > 3. there already exists simple and explicit way to get the supposed
>> benefit
>> > using the existing mechanism "exec"
>>
>> Not quite.  You still have to pick the file descriptor you want to use
>> with
>> `exec'.  But you are not being forced to use it -- by all means, if you
>> think it's not what you need or want, feel free to avoid it and encourage
>> your friends to do the same.  There have been unsuccessful new features --
>> the case-modifying expansions are one example of a swing and miss.
>>
>
> You seem to say that there are 2 aspects of this new feature, giving
>  control on the fd
> and letting the system choose the number.
>
> Let's see the first aspect, you are saying that leaving the fd open doing
> "{ : } {fd}>file"
> is a feature to let the user control the file descriptor.
>
> But why would one use this when you can do:
>
> exec {fd}>file
>
> That is there is already exec to answer the problem of letting the user
> manage the fd,
> Why would you use another new, non intuitive non consistent feature?
>

Precisely so! Who would feel the need for this (mis-)feature. Anyone who
wants to control the persistence of the fd will use exec. No-one will feel
the need for { : ; } {fd}>file or expect that it could even work!

I would expect to be able to use { : ; } {fd}>/dev/null as a nasty idiom to
find a free descriptor number, I could not have expected it to leave the
descriptor open.

And in fact to emphasise the unexpected nature, it damages the concept of
compound commands:

# will not leave fd open
sleep 5 {fd}>/dev/null

# will not leave fd open
( sleep 5 )  {fd}>/dev/null

 # will leave fd open
{ sleep 5 ; } {fd}>/dev/null

Can it be expected that using { } as an incremental edit to a script
(because an extra command needs inserted with the same IO) should leave the
descriptor dangling, but not if ( ) is used?

If too many parts of the documentation will need annotating with exceptions
it indicates a wrong expression of the feature.

For me having bashing assigning the fd number solves another problem.
>

For me too. It is a great feature. Heavenly!

But because that was not the only problem it "solved" I spent a few hours
tracking down what my problem was and isolated this behaviour.
Then I checked the documentation and saw that there was no remark to excuse
or explain this behaviour and filed a bug. Note that documentation would
have prevented me from filing a bug. It would not have helped me avoid
wasting time. I had to already track down the problem completely in order
to realise it was related to this feature.

So in short, as keeping the fd open is available through exec from ancient
times, and as it would be unexpected here, I think it is an
un-necessary confusion.

Sam