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 > ^CINT > ^CINT > ^CINT > $ echo $? $i > 0 100 > > Buggy behaviour: The 'trap' command is on a separate command line. > The signal is not ignored. The trap is executed once on Ctrl+C and the > loop is interrupted. > > $ trap 'echo INT' INT > $ i=0; while [ $((i+=1)) -lt 100 ]; do :; done > ^CINT Thanks for the report. This is actually something I had flagged to look at after bash-4.4 was released: /* XXX - why do we set this every time through the loop? And why do it if SIGINT is trapped in an interactive shell? */ It looks like not that many people trap SIGINT in an interactive shell. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
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='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I./include -I. -I./include -I./lib -DDEFAULT_PATH_VALUE='/usr/local/sbin:/ usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin' -DSTANDARD_UTILS_PATH='/bin:/usr/bin:/sbin:/usr/sbin' -DSYS_BASHRC='/etc/bash/bashrc' -DSYS_BASH_LOGOUT='/ etc/bash/bash_logout' -DNON_INTERACTIVE_LOGIN_SHELLS -DSSH_SOURCE_BASHRC -DUSE_MKTEMP -DUSE_MKSTEMP -march=native -fomit-frame-pointer -O2 -pipe 10 uname output: Linux pilgrim 4.7.4 #4 SMP PREEMPT Thu Sep 15 23:22:11 CEST 2016 x86_64 Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz GenuineIntel GNU/Linux achine Type: x86_64-pc-linux-gnu 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: read sets variable on timeout, but should not When read is used with the -t option and nothing is entered an unset variable should remain unset but it is set: $ unset var; read -t 0.5 var; declare -p var declare -- var="" $ unset var; read -t 0.5 var <<< ''; declare -p var declare -- var="" $ Sincerely Kai P.S. Thank you for making such a great tool. Repeat-By: [Describe the sequence of events that causes the problem to occur.] Fix: [Description of how to fix the problem. If you don't know a fix for the problem, don't include this section.]
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 in
>>> https://lists.gnu.org/archive/html/bug-bash/2014-11/msg00099.html
>>> ?
>>
>> There's not a compelling reason to break backwards compatibility or to be
>> unnecessarily incompatible with other shells that implement that construct,
>> like ksh93.
>
> I kind of doubt anybody would know what to expect with them. :+ and :-
> are particularly weird (they don't quite have to do with testing for
> defined variable admittedly).
This is probably true. I think all the shells with arrays try to treat
${a[@]} in the same way as $@, which gets strange in a "scalar" context.
There was a pretty extensive discussion of the $@ issue on the austin-
group mailing list, which revealed big differences in how shells expand
$@ in a "non-list" context. I think those differences are reflected in
how those shells expand ${a[@]}.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
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: > > read sets variable on timeout, but should not > > When read is used with the -t option and nothing is entered an unset > variable should remain unset but it is set: > > $ unset var; read -t 0.5 var; declare -p var > declare -- var="" > $ unset var; read -t 0.5 var <<< ''; declare -p var > declare -- var="" > $ It's a consequence of this documented behavior: "If read times out, read saves any partial input read into the specified variable name." The idea is twofold: to save partially read input that would otherwise be lost, and to allow programmers to detect that read timed out rather than hit EOF (yes, you can check the exit status, too). Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
