There are lots of txt files in a directory.If I do time wc -l *.txt | head it takes real    0m0.032suser    0m0.020ssys     0m0.008sIf I do time wc -l *.txt | tail it takesreal    0m0.156suser    0m0.076ssys     0m0.088sDoes this mean that wc will know beforehand that it is piping to head and will only count for first 10 files and save time? In other words, is it aware of the pipe? And is this somethign special about wc or does it apply to all standard/built-in commands?
Time required to do pipe output to head/tail
io redirection;pipe;tail;wc;head
I did a strace on both commands. The interessting thing is that when you pipe the output to head there are only 123 system calls. On the other hand when pipeing to tail there are 245  system calls (or more when there are more *.txt files).Case: headHere are the last few lines when pipeing to head:open(file12.txt, O_RDONLY)            = 3fadvise64(3, 0, 0, POSIX_FADV_SEQUENTIAL) = 0read(3, , 16384)                      = 0write(1, 0 file12.txt\n, 13)          = -1 EPIPE (Broken pipe)--- SIGPIPE (Broken pipe) @ 0 (0) ---+++ killed by SIGPIPE +++When wc tries to write the output of the 12th file it gets an error EPIPE. Thats why head exited after getting the 11th line. When head exits, wc gets SIGPIPE. As seen in the strace output above, wc first tries to write to that pipe (where head no longer reads from) and gets an error that the pipe is broken. The SIGPIPE signal is sent to a process when it attempts to write to a  pipe without a process connected to the other end. -- from WikipediaCase: tailWhen pipeing to tail, there is nothing like that above. wc ends gracefully after writingall the output to the pipe where tail needs to be connected to for the whole time. tail needs all lines before it can print the last 10 of them. When there is no more output to read, tail prints the lines and exits gracefully too