Re: When a hashed pathname is deleted, search PATH

On Tue 18 Mar 2014 21:11:07 Linda Walsh wrote: > Mike Frysinger wrote: > > On Tue 18 Mar 2014 01:04:03 Linda Walsh wrote: > >> Chet Ramey wrote: > >>> Because the execution fails in a child process. You'd be able to fix it > >>> for that process, but would do nothing about the contents of the pare

ctrl-c does not send INT to all processes under foreground job

Hello, guys: It is said that "ctrl-C sends INT to ALL processes under foreground job", but i found a weird phenomenon. I have not read source code yet, but it does not seem to ascribe to what specification says. Test code is like: 1 trap "echo hello world $1" 2 2 slee

Re: When a hashed pathname is deleted, search PATH

Mike Frysinger wrote: On Tue 18 Mar 2014 01:04:03 Linda Walsh wrote: Chet Ramey wrote: Because the execution fails in a child process. You'd be able to fix it for that process, but would do nothing about the contents of the parent shell's hash table. The way the option works now is to check

Re: bash cross with installed readline

On Sun 16 Mar 2014 13:30:55 Andrew Kosteltsev wrote: > When we build bash for some targets the INCLUDES variable for BUILD_CC > contains the path to target readline headers. This path points to the > target headers which not preferred for utilities which prepared for build > machine. > > Also when

Re: When a hashed pathname is deleted, search PATH

On Tue 18 Mar 2014 01:04:03 Linda Walsh wrote: > Chet Ramey wrote: > > Because the execution fails in a child process. You'd be able to fix it > > for that process, but would do nothing about the contents of the parent > > shell's hash table. > > > > The way the option works now is to check the h

Re: ${assoc[key]+set} no longer works.

On 3/18/14 5:36 AM, geir.ha...@gmail.com wrote: > Bash Version: 4.3 > Patch Level: 0 > Release Status: release > > Description: > With an associative array, assoc, ${assoc[key]+set} expands to the > empty string if the associated value is the empty string. Thanks for the report. This wa

regression: extglobs expand hidden files in 4.3

With bash-4.3 as found on Debian's 4.3-2 package: $ bash -cO extglob 'echo *(.)' . .. $ bash -cO extglob 'echo *(foo)*' . .. a $ bash -cO extglob 'echo @(|foo)*' . .. a It looks like the regression was introduced by 4.3, as 4.2 doesn't exhibit the same problem. This one's OK: $ bash -cO extglo

Re: Following symlinks in globstar

2014-02-04 09:23:21 -0500, Chet Ramey: > On 1/25/14 6:11 PM, Stephane Chazelas wrote: > > 2014-01-21 10:19:10 -0500, Chet Ramey: > > [...] > >>> I am not so worried about the method used to "fix" globstar -- whether > >>> we keep backwards compatibility or not -- I am more concerned that we > >>> h

Re: When a hashed pathname is deleted, search PATH

On 18 March 2014 08:04, Linda Walsh wrote: > > > Chet Ramey wrote: > >> Because the execution fails in a child process. You'd be able to fix it >> for that process, but would do nothing about the contents of the parent >> shell's hash table. >> >> The way the option works now is to check the has

${assoc[key]+set} no longer works.

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-unknown-linux-gnu' -DCONF_VENDOR='unknown' -DLOCALEDIR='/usr/local/share

Re: When a hashed pathname is deleted, search PATH

Chet Ramey wrote: Because the execution fails in a child process. You'd be able to fix it for that process, but would do nothing about the contents of the parent shell's hash table. The way the option works now is to check the hash lookups and delete anything that is no longer an executable f