On 3/22/2019 6:49 AM, Chet Ramey wrote:
> Yes, that's how bash chooses to implement it. There are a few portable
> ways
> to turn a string into a file descriptor, and a temp file is one of them (a
> child process using a pipe is another, but pipes have other issues).
>
Such as? That are more common that having no writeable tmp?
Pipes are the first thing that most unix programmers using
a unix-like shell on an unix-like OS think of. From
Tuesday, 2015-Oct-13 13:51:03 (-0700) on this list:
Subject: my confusion on various I/O redirections syntaxes and indirect
methods
Chet Ramey wrote:
> On 10/12/15 7:39 PM, Linda Walsh wrote:
>> 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?
----
Well, we have
"<< xxx"
as a HERE DOC using a tmp file, Some time ago, the ability to do
"multiple assignments" at the same time was added (when I asked how to
do that) that was told to use:
"read x y z <<< "one two three"
(which I initially equated to something like:
(x y z)=(one two three)
That would be like the regular assignment:
xyz=(one two three)
but with the array syntax on the left, would do word
splitting on the left and assign to the individual vars;
as I was searching for a way to do multiple assignments
in the same statement).
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')
Which I envisioned as
as implemented something like (C-ish example
off top of head using a perl-code I wrote to do the same):
int savein,saveout;
int pid;
dup2(0, savein);
dup2(1, saveout);
int inout[2];
#define stdin inout[0]
#define stdout inout[1]
pipe(&inout,O_NONBLOCK);
dupto(stdin,0);
dupto(stdout,1);
setup_childsighandler(to close 0 when child exits);
if ($pid=fork()) { #parent
dupto(saveout,1);
shell("readarray -t uservar("xyz")"); #reads from pipe:inout[0]
#child handler closes 0
dupto(savein,0);
} else if (pid==0) { #child
close(0);
shell("echo $'a\nb\nc'"); #output goes out on pipe:inout[1]
exit(0);
}
##parent continues -- no tmpfiles or named fifo's needed.
---------------
So I didn't realize instead of doing it simply using
native pipes like above, it was implemented some other way.
didn't understand the complexity of the need
for < <( to need a named pipe or fifo)....
These examples and concepts came up when I
was trying to write a bash script [running in early boot] that threw
out some error cases like /dev/fd/99 not found... [or
/tmp/tmpx2341 not found...]
> 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).
----
yeah with the "clear and unambiguous"[sic] syntax
of :
<< xxx
<<< xxx
<<< $(echo 'xxx')
< < (xxx)
I can't imagine why'd I ever have been confused -- or,
given the pipe example above -- why any of the above
had to use [diskfile] based io.
So the fact that I get confused about what extra-complex
is used for which syntax isn't that surprising to me --
is it that surprising to you that given the complexities
chosen for implementation, why some people might be
confused about remembering the details of each when
they all could have been done without any [diskfile]
confusions??
======================================================================
(end quoted email)
Using tmp files instead of pipes is what MSDOS used to do to
emulate pipes that unix had. It was slow, clunky and not reliable
because the underlying file system wasn't always writeable.
