Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > gnu.bash.bug > #11710

Re: Design question(s), re: why use of tmp-files or named-pipes(/dev/fd/N) instead of plain pipes?

From Linda Walsh <bash@tlinx.org>
Newsgroups gnu.bash.bug
Subject Re: Design question(s), re: why use of tmp-files or named-pipes(/dev/fd/N) instead of plain pipes?
Date 2015-10-19 12:49 -0700
Message-ID <mailman.654.1445284185.7904.bug-bash@gnu.org> (permalink)
References <56218DA5.8030501@tlinx.org> <5622CDC8.2030102@case.edu> <5622EB23.6020700@tlinx.org> <20151019122800.GS27325@eeg.ccf.org>

Show all headers | View raw



Greg Wooledge wrote:
> On Sat, Oct 17, 2015 at 05:43:15PM -0700, Linda Walsh wrote:
>> Chet Ramey wrote:
>>> I think you're missing that process substitution is a word expansion
>>> that is defined to expand to a filename.
>> -----
>> 	??? I've never seen a usage where it expands to a filename and
>> is treated as such.
> 
> A simple example:
> 
> diff -u <(sort file1) <(sort file2)
----
	You claim <(sort file1) is a filename?

> touch a
> mv <(sort a) <(sort a)         
mv: cannot move ‘/dev/fd/63’ to ‘/dev/fd/62’: Operation not permitted 

The OS claims that <() generates a file descriptor -- not a filename.

"<()" is not the same, nor equivalent to a filename.  It represents
a *file descriptor* that you can perform stream I/O on.  

It's the same with 'FILENAME'a used with "read < FILENAME >FILENAME"

> read < FILE > FILE
-bash: FILE: No such file or directory   # no file is created by '>'
> echo content >FILE
> read mycontent < FILE >FILE
> echo $mycontent			# empty: file truncated before read
> a=<(sort a); chmod +x "$a"
chmod: cannot access ‘/dev/fd/63’: No such file or directory
> echo aaa > a
> read var <(sort a) && echo "var=$var" >a

## the above hangs: if <(sort a), was a filename, read would
## have read 'aaa' ## from it, and returned immediately.  
## Then the 'echo' command would have put 'var=aaa' 
## in 'a': instead:
> cat a
aaa

The above operations show that <() is not equivalent to a filename.
It only returns a 'path' to a *device* that doesn't have file semantics
and can only be opened for read... and even that doesn't
appear to work all the time.

I observe similar inconsistencies and confusion around
the use of 'dynamic vars' -- not really being global, not really
being local, but supposedly on some dynamic frame, "somewhere",
but not anywhere they've been declared or used.




Back to gnu.bash.bug | Previous | Next | Find similar


Thread

Re: Design question(s), re: why use of tmp-files or named-pipes(/dev/fd/N) instead of plain pipes? Linda Walsh <bash@tlinx.org> - 2015-10-19 12:49 -0700

csiph-web