Re: Segmentation fault in pat_subst

On Sun, Jul 21, 2019 at 06:56:09PM -0400, Chet Ramey wrote: (...) > Thanks for the report. Look at match_wpattern and consider what happens if > wmatchlen returns something longer than the string length. It will be fixed > for the next devel branch push. Aha! I see. | Starting program:

Comment before 'else' on CLI, does not save to history correctly

Version: bash --version GNU bash, version 4.4.23(1)-release (x86_64-redhat-linux-gnu) Copyright (C) 2016 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software; you are free to change and redistribute it. There is NO

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

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

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

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

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

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,

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.

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.

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

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,

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

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':

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'