Path: csiph.com!optima2.xanadu-bbs.net!xanadu-bbs.net!news.glorb.com!usenet.stanford.edu!not-for-mail
From: Chet Ramey <chet.ramey@case.edu>
Newsgroups: gnu.bash.bug
Subject: Re: read and env variables + POSIX => SEGFAULT
Date: Mon, 12 Oct 2015 20:39:22 -0400
Organization: ITS, Case Western Reserve University
Lines: 80
Approved: bug-bash@gnu.org
Message-ID: <mailman.190.1444696775.7904.bug-bash@gnu.org>
References: <CAAZkfoJuwe4o1rPQrfB-vxqeAaBX-=9NPWgv2uiOPdHq7L8g+g@mail.gmail.com> <5619D0F1.6080904@tlinx.org> <561C2097.5080808@case.edu> <561C4456.9020308@tlinx.org> <561C44C1.9000004@tlinx.org>
Reply-To: chet.ramey@case.edu
NNTP-Posting-Host: lists.gnu.org
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Trace: usenet.stanford.edu 1444696775 31813 208.118.235.17 (13 Oct 2015 00:39:35 GMT)
X-Complaints-To: action@cs.stanford.edu
Cc: chet.ramey@case.edu
To: Linda Walsh <bash@tlinx.org>, bug-bash <bug-bash@gnu.org>
Envelope-to: bug-bash@gnu.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
In-Reply-To: <561C44C1.9000004@tlinx.org>
X-Junkmail-Whitelist: YES (by domain whitelist at mpv2.tis.cwru.edu)
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic]
X-Received-From: 129.22.105.37
X-BeenThere: bug-bash@gnu.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: Bug reports for the GNU Bourne Again SHell <bug-bash.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/bug-bash>, <mailto:bug-bash-request@gnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/archive/html/bug-bash>
List-Post: <mailto:bug-bash@gnu.org>
List-Help: <mailto:bug-bash-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/bug-bash>, <mailto:bug-bash-request@gnu.org?subject=subscribe>
Xref: csiph.com gnu.bash.bug:11641

On 10/12/15 7:39 PM, Linda Walsh wrote:

>>>> 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?)
>>
>> This is terribly wrong.
>>
>> The command in question is `a= read a <<< x'.
>>
>> The here-string construct takes the following word and, like a here
>> document, makes it the standard input to the command.  The standard
>> input is then a file consisting of a single line: x\n.
>>
>> It's basically shorthand for
>>
>> read a <<EOF
>> x
>> EOF
>>
>> So, `read' reads the single line from its standard input and assigns it
>> to the variable `a'.
> ----
> I wasn't sure if it put the "\n" at the end in a 1-line example.

Yes.  All the lines in a here-document or here-string are newline-
terminated.

> Does it also use a tmp file and use process-substitution, or is
> that only when parens are present?

Here-documents and here-strings use temporary files and open them as
the standard input (or specified file descriptor) for the command.

> 
> read a < <( echo x)
> 
> I'm under the impression, uses a tmp file.

Why would you think that?  The documentation clearly says it uses a named
pipe or a file descriptor associated with a /dev/fd filename (which happens
to be a pipe in this case).

> 
> does the read a <<< x
> also use a tmp file?

Yes.

> 
> I.e. is
>> readarray -t a < <( echo -e 'x\ny\n')
>> declare -p a
> declare -a a='([0]="x" [1]="y")'
> 
> implemented the same way as
>> a=(x y)
>> b=$(printf "%s\n" ${a[@]})
>> readarray -t ar <<< "${b[@]}"
>> declare -p a
> declare -a a='([0]="x" [1]="y")'

No, if you mean the type of object the `readarray' command has associated
with its standard input.  The first case is a pipe or FIFO; the second is
a regular file.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/