Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > gnu.bash.bug > #11710
| 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> |
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
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