cat file | wc | cat > file2
would usually be two useless uses of
cat as that's functionally equivalent to:
< file wc > file2
However, there may be a case for:
cat file | wc -c
< file wc -c
That is to disable the optimisation that many
wc implementations do for regular files.
For regular files, the number of bytes in the file can be obtained without having to read the whole content of the file, but just doing a
stat() system call on it and retrieve the size as stored in the inode.
Now, one may want the file to be read for instance because:
Of course, those are exceptions. In the general case, you'd rather use
< file wc -c for performance reasons.
Now, you can imagine even more far fetched scenarios where one may want to use:
cat file | wc | cat > file2:
wc has an apparmor profile or other security mechanism that prohibits it from reading or writing to files while it's allowed for
cat (that would be unheard of)
cat is able to deal with large (as in > 232 bytes) files, but not
wc on that system (things like that have been needed for some commands on some systems in the past).
- maybe one wants
wc (and the first
cat) to run and read the whole file (and be killed at the very last minute) even if
file2 can't be open for writing.
- maybe one wants to hide the failure (exit status) of opening or reading the content of
wc < file > file2 || : would make more sense.
- maybe one wants to hide (from the output of
lsof (list open files)) the fact that he's getting a word count from
file or that he's storing a word count in