Shell Programming and Scripting

Yes, in a way, they are, and you are correct to state that the functionality of the original script is not altered by their absence. My intention in putting them there was only to emphasize how a child script (such as a background process, or a parenthesized section in a script) can pass data to it's parent.

I'm very glad you find the thread interesting, and I appreciate the multiple features of different shells you have provided.

EDIT:

Now that I take a good look at it, you're right! The background process...

Code:

echo 'value' > $TMPFIFO &

...is already in a subshell!, so yes, the parentheses come out as completely superfluous... I get you now, loud and clear. In that sense, I guess you could say that the parentheses show that, no matter how deep the ancestry gets, the fifo will always be there to communicate all of it's levels.

---------- Post updated at 02:37 PM ---------- Previous update was at 02:04 PM ----------

Ok, here; what is the difference between using exec and doing...

Code:

{  sleep 2; ps -f ;echo "hello from $FIFO" ;} > "$FIFO" &

...instead? I seem to get the same results with both. But you say that:

What do you mean by "goes on after the first command writes an EOF"?

EDIT:

Unless you're talking about using exec instead of using redirection for each write statement (as opposed to for the whole curly braces, which is what I did here). For example, when I tried:

Code:

#!/bin/bash
FIFO="/tmp/fifo.$$"
if ! [ -p "$FIFO" ]; then
  mkfifo "$FIFO"
fi
{ echo 1 > $FIFO ; echo 2 > $FIFO ; echo 3 > $FIFO ; echo 4 > $FIFO ; echo 5 > $FIFO ; } &
var=$(< "$FIFO")
rm "$FIFO"
echo "$var"

I got varying results for each time I ran it. Fifo redirection for each write statement malfunctions here.

EDIT2:

BTW, thanks for the tip on coprocesses, I've never really used them, or even heard about them before, but it's good to know that the option exists.

I mean that one should avoid:

Code:

{ sleep 2; ps -f > "$FIFO"; echo "hello from $FIFO" > "$FIFO" ;} &

using exec is just one way of avoiding that...

Code:

{ exec >"$FIFO"; sleep 2; ps -f ;echo "hello from $FIFO" ;} &

regarding EDIT: That's right

It does not malfunction, the subprocess opens and closes stdout and therefore the varying results. I used a sleep statement so that the reading process would be reading before the subprocess started opening the pipe...

Ahhh... so the trick is in the timing then... Nice one.

---------- Post updated 03-27-12 at 12:57 PM ---------- Previous update was 03-26-12 at 03:08 PM ----------

I recently found this unusual shell notation in a linux journal article:

Code:

command <(compound-list)

This creates a temporal fifo which is inputted whatever output the list of commands compound-list produces, and thus, command treats this output as if it belonged to a file. This way, <(compound-list) is treated as if it were a common filename. This must be an exclusive bash feature, since I don't recall reading of it in any of the shell programming books I've read, and when I tried looking it up in POSIX.1-2008 (not too thoroughly, I admit) I found it also says nothing about this feature. The feature appears in the Bash Reference Manual, under the section 3.5.6. Process Substitution.

Anyway, I thought it was worth mentioning it, since it's loosely related to this thread.