Path: csiph.com!optima2.xanadu-bbs.net!xanadu-bbs.net!news.glorb.com!usenet.stanford.edu!not-for-mail From: Linda Walsh Newsgroups: gnu.bash.bug Subject: my confusion on various I/O redirections syntaxes and indirect methods Date: Tue, 13 Oct 2015 13:51:03 -0700 Lines: 123 Approved: bug-bash@gnu.org Message-ID: References: <5619D0F1.6080904@tlinx.org> <561C2097.5080808@case.edu> <561C4456.9020308@tlinx.org> <561C44C1.9000004@tlinx.org> <561C52BA.2070205@case.edu> NNTP-Posting-Host: lists.gnu.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: usenet.stanford.edu 1444769561 4604 208.118.235.17 (13 Oct 2015 20:52:41 GMT) X-Complaints-To: action@cs.stanford.edu Cc: bug-bash To: chet.ramey@case.edu Envelope-to: bug-bash@gnu.org User-Agent: Thunderbird In-Reply-To: <561C52BA.2070205@case.edu> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x (no timestamps) [generic] X-Received-From: 173.164.175.65 X-BeenThere: bug-bash@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports for the GNU Bourne Again SHell List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Xref: csiph.com gnu.bash.bug:11652 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 that threw out some error cases like /dev/fd/99 not found... or such or implemented some other way /tmp/foobar not found... (both of which I thought were mounted, but wasn't sure -- but then wondered why a tmpfile or named pipe was needed for EITHER implementation... both can be done with native pipes like above, no external "linux-isms" or files needed -- and I'm certain the execution speed would be no worse (likely better than using tmp files or named pipes/fifos). > 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 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 "pathname" 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 pathname confusions??