Path: csiph.com!xmission!news.glorb.com!usenet.stanford.edu!not-for-mail From: Linda Walsh Newsgroups: gnu.bash.bug Subject: Re: read and env variables + POSIX => SEGFAULT Date: Sat, 10 Oct 2015 20:01:05 -0700 Lines: 90 Approved: bug-bash@gnu.org Message-ID: References: NNTP-Posting-Host: lists.gnu.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: usenet.stanford.edu 1444532477 7171 208.118.235.17 (11 Oct 2015 03:01:17 GMT) X-Complaints-To: action@cs.stanford.edu To: isabella parakiss , bug-bash Envelope-to: bug-bash@gnu.org User-Agent: Thunderbird In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x (no timestamps) [generic] X-Received-From: 173.164.175.65 X-BeenThere: bug-bash@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports for the GNU Bourne Again SHell List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Xref: csiph.com gnu.bash.bug:11610 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 > 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