Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > gnu.bash.bug > #11636
| From | Chet Ramey <chet.ramey@case.edu> |
|---|---|
| Newsgroups | gnu.bash.bug |
| Subject | Re: read and env variables + POSIX => SEGFAULT |
| Date | 2015-10-12 17:05 -0400 |
| Message-ID | <mailman.173.1444683941.7904.bug-bash@gnu.org> (permalink) |
| References | <CAAZkfoJuwe4o1rPQrfB-vxqeAaBX-=9NPWgv2uiOPdHq7L8g+g@mail.gmail.com> <5619D0F1.6080904@tlinx.org> |
On 10/10/15 11:01 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'. -- ``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/
Back to gnu.bash.bug | Previous | Next | Find similar
Re: read and env variables + POSIX => SEGFAULT Chet Ramey <chet.ramey@case.edu> - 2015-10-12 17:05 -0400
csiph-web