Re: Bug for the 'read' build in

On 11/9/16 10:42 AM, Kai Pöritz wrote: > Bash Version: 4.3 > Patch Level: 48 > Release Status: release > > Description: > Dear Chet Ramey, > > I think I found a bug in the read build in. I described it at: > > https://savannah.gnu.org/support/index.php?109181 > > But I'll write it here again:

Re: 4.4 change in behavior from 4.3: how to catch unset when using ${#length}

On 11/7/16 4:49 AM, Dan Douglas wrote: > On Sun, Nov 6, 2016 at 3:46 PM, Chet Ramey wrote: >> On 11/1/16 5:57 AM, Dan Douglas wrote: >>> On a possibly related note, would you consider adjusting +, :+, -, :-, >>> as in "${var[@]+word}" to align with the meaning of [[ -v var[@] ]] as >>> discussed i

Bug for the 'read' build in

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

Re: SIGINT kills interactive shell from dot script

On 11/8/16 1:50 PM, Martijn Dekker wrote: > Works as expected: The 'trap' command is on the same command line as the > loop. The signal is properly ignored, the trap is properly executed > repeatedly on pressing Ctrl+C. > > $ trap 'echo INT' INT; i=0; while [ $((i+=1)) -lt 100 ]; do :; done >