On 4/7/19 4:21 PM, L A Walsh wrote:
> 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 objectively not the same as files. They
1. Do not have file semantics. For instance, they are not seekable.
2. Have limited capacity. Writers will sleep when the pipe becomes full.
3. Have ordering constraints: you can't write a pipe with no reader, for
instance.
These, unlike a "no writeable tmp," have been around for as long as pipes
have existed in Unix.
There is a middle ground, which is to use pipes for here documents that
are shorter than the pipe capacity, but fall back to temp files for
others, which doesn't require a child process. I implemented that in the
devel version.
> 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
I don't think you've ever really understood that these are two separate
constructs: process substitution, which turns a process into a filename
you can write to and read from for various purposes, and input redirection.
> So I didn't realize instead of doing it simply using
> native pipes like above, it was implemented some other way.
And that's probably why.
>
> didn't understand the complexity of the need
> for < <( to need a named pipe or fifo)....
That, too.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU c...@case.edu http://tiswww.cwru.edu/~chet/
