Re: leaks fd for internal functions but not external command

This just made me sad: tedious_function() { : # lots of stuff } {BASH_XTRACEFD}>/dev/null it would be so cool to be able to disable debug output BASH_XTRACEFD like that whether or not BASH_XTRACEFD was set. I guess the variable would have to be local to the function invocation too. Please add

Re: leaks fd for internal functions but not external command

On 7/25/19 9:03 AM, Sam Liddicott wrote: > Perhaps if the named fd is also closed on the same statement that opened > it, it could be kept closed rather than saved and re-opened. > Being closed at the same statement is a strong indicator that it was only > used to aid fd transplants. Why keep open

Re: leaks fd for internal functions but not external command

Thanks for your continued engagement, it is appreciated. I was focused on my case where I used _ as the name of the file descriptor because I didn't want to retain it, for I was using named fd as a way to avoid trampling on an fd already in use, rather than as an open method. I'm writing up a she

leaks fd for internal functions but not external command

On 7/24/19 9:07 AM, Sam Liddicott wrote: > Thanks for that thoughtful response. > > * I understand that the design decision is to have variable file > descriptors to stay open after per-command redirection Yes. > * I understand that implementation constraints make it impossible to do > this unif

Re: leaks fd for internal functions but not external command

Thanks for that thoughtful response. * I understand that the design decision is to have variable file descriptors to stay open after per-command redirection * I understand that implementation constraints make it impossible to do this uniformly (for external command redirection) * I understand that

Re: leaks fd for internal functions but not external command

On 7/23/19 5:15 PM, Sam Liddicott wrote: > I'm very surprised that you continue to insist that it should be a *design* > decision that it should be hard for a script writer to be able to tell if a > handle will be left open or not. What? The design decision is that a file descriptor opened with {v

Re: leaks fd for internal functions but not external command

I'm very surprised that you continue to insist that it should be a *design* decision that it should be hard for a script writer to be able to tell if a handle will be left open or not. What could be the rationale for such a design decision? The vague justification you provide "there are plenty of

Re: leaks fd for internal functions but not external command

On 7/23/19 12:12 PM, Sam Liddicott wrote: > Given what you have explained as intentional, it the difference between 1 > and 2, but it is best understood as a 4-way difference, outlined here: > > 1. {var} internal: fd remains open in parent > 2. {var} external: fd closed in parent > 3. numeric int

Re: leaks fd for internal functions but not external command

On Tue, 23 Jul 2019 at 16:45, Chet Ramey wrote: > On 7/23/19 11:40 AM, Sam Liddicott wrote: > > > > On Tue, 23 Jul 2019 at 16:35, Chet Ramey > > wrote: > > > > On 7/23/19 11:20 AM, Sam Liddicott wrote: > > > > > > On Tue, 23 Jul 2019 at 16:15, Sam Liddicot

Re: leaks fd for internal functions but not external command

On Tue, Jul 23, 2019 at 04:40:03PM +0100, Sam Liddicott wrote: > Is using {xxx}>... suppose to give me a file handle I can use as I wish (as > you say), or not? > > Using explicit descriptors e.g. 10>... behaves consistently whether the the > command is internal or external. > > Having bash alloc

Re: leaks fd for internal functions but not external command

On 7/23/19 11:40 AM, Sam Liddicott wrote: > > On Tue, 23 Jul 2019 at 16:35, Chet Ramey > wrote: > > On 7/23/19 11:20 AM, Sam Liddicott wrote: > > > > On Tue, 23 Jul 2019 at 16:15, Sam Liddicott > >

Re: leaks fd for internal functions but not external command

On Tue, 23 Jul 2019 at 16:35, Chet Ramey wrote: > On 7/23/19 11:20 AM, Sam Liddicott wrote: > > > > On Tue, 23 Jul 2019 at 16:15, Sam Liddicott > > wrote: > > > > > > > > On Tue, 23 Jul 2019 at 16:13, Chet Ramey > > wrote: > > > >

Re: leaks fd for internal functions but not external command

On Jul 23 2019, Sam Liddicott wrote: > It got closed in the parent. The lsof is running for the parent, the main > process. /bin/echo has quit before the lsof runs. When you run an external command the redirection is performed in the child. Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.d

Re: leaks fd for internal functions but not external command

On 7/23/19 11:20 AM, Sam Liddicott wrote: > > > On Tue, 23 Jul 2019 at 16:15, Sam Liddicott > wrote: > > > > On Tue, 23 Jul 2019 at 16:13, Chet Ramey > wrote: > > On 7/23/19 11:11 AM, Sam Liddicott wrote: > > >

Re: leaks fd for internal functions but not external command

On Tue, 23 Jul 2019 at 16:15, Sam Liddicott wrote: > > > On Tue, 23 Jul 2019 at 16:13, Chet Ramey wrote: > >> On 7/23/19 11:11 AM, Sam Liddicott wrote: >> >> > The report concerns the different behaviour with internal and external >> > operations. >> >> Right. The close-on-exec is deliberate. Th

Re: leaks fd for internal functions but not external command

On 7/23/19 11:15 AM, Sam Liddicott wrote: > > > On Tue, 23 Jul 2019 at 16:13, Chet Ramey > wrote: > > On 7/23/19 11:11 AM, Sam Liddicott wrote: > > > The report concerns the different behaviour with internal and external > > operations. > > Right. T

Re: leaks fd for internal functions but not external command

On Tue, 23 Jul 2019 at 16:13, Chet Ramey wrote: > On 7/23/19 11:11 AM, Sam Liddicott wrote: > > > The report concerns the different behaviour with internal and external > > operations. > > Right. The close-on-exec is deliberate. That's how it was intended. > Doesn't close-on-exec usually takes e

Re: leaks fd for internal functions but not external command

On 7/23/19 11:11 AM, Sam Liddicott wrote: > The report concerns the different behaviour with internal and external > operations. Right. The close-on-exec is deliberate. That's how it was intended. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita

Re: leaks fd for internal functions but not external command

On Tue, 23 Jul 2019 at 16:05, Chet Ramey wrote: > On 7/23/19 10:33 AM, Sam Liddicott wrote: > > > Bash Version: 4.4 > > Patch Level: 20 > > Release Status: release > > > > Description: > > Bash redirection sequence cases a file descriptor to be leaked > > if the main command is an internal functi

Re: leaks fd for internal functions but not external command

On 7/23/19 10:33 AM, Sam Liddicott wrote: > Bash Version: 4.4 > Patch Level: 20 > Release Status: release > > Description: > Bash redirection sequence cases a file descriptor to be leaked > if the main command is an internal function but not if it is > an external command. It's not `leaked': you

leaks fd for internal functions but not external command

Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE