bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: my confusion on various I/O redirections syntaxes and indirect metho


From: Greg Wooledge
Subject: Re: my confusion on various I/O redirections syntaxes and indirect methods
Date: Tue, 13 Oct 2015 17:11:58 -0400
User-agent: Mutt/1.4.2.3i

On Tue, Oct 13, 2015 at 01:51:03PM -0700, Linda Walsh wrote:
>       Well, we have 
> "<< xxx"
> as a HERE DOC using a tmp file

Correct.  Note that xxx is just the sentinel to tell bash where the here
document ends.  It's not part of the data.

> , Some time ago, the ability to do 
> "multiple assignments" at the same time was added (when I asked how to 
> do that)

You are confused.  Nothing was added.

> that was told to use:
> 
> "read x y z <<< "one two three"

This is simply how the read commands works.  If you give read three
variable names, it will break the line into fields (assuming IFS is not
empty) and assign the first field to the the first variable, the second
field to the second variable, and THE ENTIRE REMAINING LINE (delimiters
and all!) to the third variable.

>   (which I initially equated to something like:
> (x y z)=(one two three)

You are mixing things up.  There are two different pieces of syntax
here: the read command, and the here string syntax.

The here string syntax <<< is exactly like a here document << except that
the here string is a single word terminated by a newline (or by quoting)
instead of by a specified delimiter.

The following two pieces of code are exactly the same:

read x y z <<< "an input string"

read x y z << EOF
an input string
EOF

Moreover, the following two pieces of code give the same resulting
variable contents:

read x y z <<< "a much longer input string"

read x y z << EOF
a much longer input string
with some other lines
after it
EOF

In both cases, z="longer input string".  The extra lines in the second
code piece are not used, because read stops reading at the first newline.

> Then came along a way to do a process in background and end up
> with being able to read & process its data in the main (foreground) 
> process w/this syntax:
> 
> readarray -t foregnd < <(echo  $'one\ntwo\nthree')

This is process substitution.  It's not like here documents/here strings
which use a temp file and syntactic delimiters.  It runs a command in
the background and establishes a named pipe (or uses a /dev/fd/* entry,
depending on the platform) to connect the background process to the
foreground command.

The <(...) construction is replaced by the name of the FIFO or the
/dev/fd/* entry.  So as far as the foreground command is concerned, it
is simply an input redirection:

readarray -t foregnd < something

The "something" happens to be a magical pipe/fd thing, that's all.
The key is that it's somewhere in the file system, which allows an
input redirection to point to it.  readarray doesn't know anything
magical is happening.  It just reads standard input.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]