4 ms·
right from the start it's teaching bad practices [1]. You do not need to 'cat file.txt' when all tools can take file.txt as input directly without it being cat'
by sigmonsays 3y ago
right from the start it's teaching bad practices [1]. You do not need to 'cat file.txt' when all tools can take file.txt as input directly without it being cat'd.
https://porkmail.org/era/unix/award https://porkmail.org/era/unix/award
For a crew of people who read hackernews i'd expect something a bit more complicated. Perhaps just allow the user to write their own commands instead of doing that silly gui programming block thing?
- williamcotton 3y agoThat’s debatable. It’s a lot easier to swap things around if you use cat at the start of your pipeline and gives the data flow a complete left to right reading. For one liners I will probably < but for a shell script I’ll go with cat. Like, if you originally < into awk but then you want to < into grep first because you realized some new requirement you can’t simply swap around a “cmd |” pair.
- sltkr 3y agoI agree with you that `cat` is not really useless when it makes the code more readable, and the common idiom of `cat input-file | process | process | process > output-file` can be more readable than `process <input-file | process | process > output-file`, while the theoretical performance overhead incurred by the needless cat is negligible in the majority of cases. But for the sake of completeness I need to point out that technically I/O redirections can occur anywhere in the command line, so if you want to maintain left-to-right reading order, you can do that without resorting to cat, by writing: <input-file process | process | process >output-file For example: </etc/passwd awk -v FS=: '{ print $7 }' Works just as well as the more idiomatic: awk -v FS=: '{ print $7 }' /etc/passwd