Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > gnu.bash.bug > #11610
| From | Linda Walsh <bash@tlinx.org> |
|---|---|
| Newsgroups | gnu.bash.bug |
| Subject | Re: read and env variables + POSIX => SEGFAULT |
| Date | 2015-10-10 20:01 -0700 |
| Message-ID | <mailman.74.1444532476.7904.bug-bash@gnu.org> (permalink) |
| References | <CAAZkfoJuwe4o1rPQrfB-vxqeAaBX-=9NPWgv2uiOPdHq7L8g+g@mail.gmail.com> |
isabella parakiss wrote: > $ a= read a <<< x # this creates a variable in the current shell > $ declare -p a > declare -- a="x" > > $ b= mapfile b <<< x # this doesn't > $ declare -p b > bash: declare: b: not found ---- Very good point... more interesting is adding posix mode to the mix: # first verify a and b are not defined > set -o posix > declare -p a bash: declare: a: not found > declare -p b bash: declare: b: not found > a= read a <<< x;echo $? 0 > declare -p a declare -- a="x" # the manpage claims "one line is read from [the input], and the result # is split by words and assigns 1st word to 1st var and so forth, but # apparently the reading of 1 line is optional -- though this is consistent # with the fact that read can be told to read some number of characters and # return when the limit is reached. So technically, read doesn't "read one line", # but read whatever is on 'input' up to 1 line. (DOC clarification?) # assigning & trying to read 2 vars but only having content for 1: > a= b= read a b <<< x > declare -p a b declare -- a="x" declare -- b="" # this is odd: 2vars with content for 2: > unset a b > a= b= read a b <<< x y > declare -p a b declare -- a="x" declare -- b="" # -- where did "y" go? # doing the same thing posix mode (as it disallows various # vague or unclear constructs) yields mostly the same results # except for your mapfile case (didn't try any further testing of # variations because of the results (2 flavors)): > b= mapfile b <<< x; echo $? 0 > declare -p b Segmentation fault (core dumped) # another example of bash not returning consistent errno results # ( |;>| ducking while smirking) ok, I vote for disallowing this # type of result return. The 2nd flavor: > b= mapfile b a <<< x > declare -p a b bash: declare: a: not found Segmentation fault (core dumped) # odd, this time it dumped on printing 'b'; still not so great # status returning... # hmmm... I'm guess fixing these to not return segfaults won't # get me any better status returns in 'type -P' # vitals: > $0 --version GNU bash, version 4.3.39(1)-release (x86_64-unknown-linux-gnu) Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> > whence bash bash is /bin/bash Ishtar:/Torrents/Library/2014Q1> ldd /bin/bash linux-vdso.so.1 (0x00007fff396eb000) libdl.so.2 => /lib64/libdl.so.2 (0x0000003001400000) libc.so.6 => /lib64/libc.so.6 (0x0000003000c00000) /lib64/ld-linux-x86-64.so.2 (0x000055da52cbc000) > uname -a Linux Ishtar 4.1.0-Isht-Van #2 SMP PREEMPT Tue Jun 23 07:52:09 PDT 2015 x86_64 x86_64 x86_64 GNU/Linux
Back to gnu.bash.bug | Previous | Next | Find similar
Re: read and env variables + POSIX => SEGFAULT Linda Walsh <bash@tlinx.org> - 2015-10-10 20:01 -0700
csiph-web