cat <<lim | sleep 5 | ls >file2 | cat <<lim | grep wow | cat <<lim
In this example, I don't understand why sleep execution begins at the conclusion of the execution. If any of you have a source or explanation of how this here document works and how he saves the data he gets from input, please share.
DON'T DO THIS.
A pipe character basically attaches the stdout of its left operand to the stdin of its right operand. That's what it is for.
Why would you ever do this?
ls >file2 | cat <<lim # 2 redirections out, 2 in!
Putting >file2 on the ls redirects its output to file2.
There is nothing for the pipe.
putting a here-doc on cat redirects its input from the HERE portion, so again, it ignores the pipe. Why do you have pipes here at all?
If you just want these things to happen simultaneously, then
ls >file2 & cat <<lim
but I confess I really have no idea what you did want. Were there local files names wow and lim that you expected to change the behavior of the pipelines? I can't tell.
Try looking over these. Hope they help.
To elaborate -
input to any process is by default on fd0.
That is usually the console, e.g., your keyboard.
Redirecting from a file (cat < file) attaches fd0 to that file.
Piping data in is another form of redirection, replacing fd0 -
e.g., echo foo | grep -o oo which should output oo.
here-docs are another form of input redirection.
Command-line redirections for a given stream are all implemented in order, as given. Thus, given echo 2>2,
$: cat # read keyboard; end with CTRL_D, gives it right back.
hi!<CTRL_D>
hi!
$: cat <<< bar # reads from the here-string
bar
$: echo 1 | cat # reads from the pipe
1
But if you start mixing them, whichever redirection happened last will be in effect.
$: echo 1 | cat <<< bar <<END # reads from the here-DOC as last
3
END
3
$: echo 1 | cat <<END <<< bar # reads from the here-STRING as last
3
END
bar
$: echo 1 | cat <<END <<< bar <2 # reads from the file 2 as last
3
END
2
$: echo 1 | cat <<END <<< bar <2 < <(echo 4) # reads the echo 4
3
END
4
These same principles apply for output redirections.
This is the principle that allows shuffling file descriptors...
ls bogus 2 2>&1 >log | tee err >&2
This tries to list the file 2 we used above and a non-existent file named bogus. It will redirect fd2, the error stream, to wherever fd1 is currently going, which defaults to "stdout"; Then it redirects fd1 to the file named log leaving only the error stream going to stdout. Then the pipe character connects stdout to the stdin of the tee program, which duplicates it to the file named err as well as its own stdout, which is redirected back to the stderr stream.
The result is that the 2 reports to log, but the error for bogus reports both to the screen (on stderr) and to the err file.
But don't do this unless you KNOW WHY and exactly what you are doing.
