Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > gnu.bash.bug > #11610

Re: read and env variables + POSIX => SEGFAULT

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>

Show all headers | View raw



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


Thread

Re: read and env variables + POSIX => SEGFAULT Linda Walsh <bash@tlinx.org> - 2015-10-10 20:01 -0700

csiph-web