Re: read builtin disregards IFS when interrupted by trapped signal
On 7/20/16 9:01 AM, Andriy Martynets wrote: > Bash Version: 4.3 > Patch Level: 42 > Release Status: release > > Description: > The read builtin disregards (or sporadically uses unpredictable value of) > the IFS variable when is interrupted by a trapped signal. > > Repeat-By: > - install a trap for a signal, say SIGALRM or SIGUSR1 > - cycle read from a process with a custom IFS to split read string into > variables > - each interrupted read will return the string splitted in wrong way Thanks for the report. The traps shouldn't assume and run with the temporary environment. This will be fixed in bash-4.4. 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/
read builtin disregards IFS when interrupted by trapped signal
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='bash'
-DSHELL -DHAVE_CONFIG_H -I. -I../. -I.././include -I.././lib
-D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector-strong -Wformat
-Werror=format-security -Wall
uname output: Linux admin-laptop-debian 4.4.0 #4 SMP Sat May 14 22:23:09
EEST 2016 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 4.3
Patch Level: 42
Release Status: release
Description:
The read builtin disregards (or sporadically uses unpredictable value of)
the IFS variable when is interrupted by a trapped signal.
Repeat-By:
- install a trap for a signal, say SIGALRM or SIGUSR1
- cycle read from a process with a custom IFS to split read string into
variables
- each interrupted read will return the string splitted in wrong way
Attached script demonstrates the bug.
Thank you in advance.
With best regards,
Andriy Martynets
#!/bin/bash
ring()
{
:
}
trap ring SIGALRM
{
while true
do
sleep 2
kill -s SIGALRM $$
done
} & # run an "alarm clock" that rings the parent every second second
while IFS=$'=' read key value
# while read key
do
# value=${key#*=}
# key=${key%%=*}
echo Read: key=\"$key\" value=\"$value\"
done < <(
# This is to emulate a process which output we read
while true
do
sleep 1
echo key=value
done
)
exit
Re: "until continue" causes bash to exit.
On 07/19/2016 09:45 PM, Chet Ramey wrote:
> On 7/19/16 7:15 PM, Dan Douglas wrote:
>> Hi, I could reproduce this in all bash versions.
>>
>> bash -c 'set -x; until continue; do :; done; echo test1'; echo test2
>> + continue
>> test2
>>
>> I'm not actually sure whether this is supposed to work at all. Almost
>> all shells do something strange when given continue in the first
>> compound-list. E.g. ksh93 does like bash and exits, and zsh breaks
>> out of the loop.
>
> It should probably print `test1'
That's what I figured. Playing around with this test the current bash
continues an outer loop if levels=1 while the "normal" ones (dash/mksh)
do so at levels=2. I suppose technically a script that before would
have continued the n+1th nested loop will now be off by one. (Not too
likely such a script exists or they would have noticed this.)
$ { bash /dev/fd/9; echo; } 9<<\EOF
set -x; n=-1 levels=1
let 1 2>/dev/null || let() { IFS=, command eval test '$(($*))' -ne 0; }
until
echo 1
let n+=1 && break
do
until
echo 2;
continue "$levels"
do :
done
echo 3
done
EOF
+ n=-1
+ levels=1
+ let 1
+ echo 1
1
+ let n+=1
+ echo 2
2
+ continue 1
+ echo 1
1
+ let n+=1
+ break
signature.asc
Description: OpenPGP digital signature
