Hacker News Reader

Comment by enriquto | Hacker News Reader

That meme "useless use of cat" is a major pet peeve of mine...

It makes no sense. Starting your pipe with cat is alright. I make a point of always starting all my pipes with cat, even in the cases where it is a bit unnatural.

View on HN

It's one more process to run, so `cat single_file | ` can be easily substituted with `<single_file `.

I was going to point this out too.

For those who may not know, you can put the I/O redirection anywhere in the command, not just at the end.

So you can write

    < input_file.txt grep some_pattern | grep another

Which has the same effect as

    grep some_pattern < input_file.txt | grep another

but puts the input redirection at the beginning so you can easily follow the data flow from left to right.

I use "redirection first" in other cases such as

1>&2 echo "Error: missing file"

To make it clear up-front that I'm writing to stderr.

Or plain `>&2` since the `1` is implied for '>'

Yep. Writing "<file " is just as good as "cat file |". Still I'm more used to writing cat. The only (marginal) advantage of cat over explicit redirection at the beginning is maybe that you can split the lines more cleanly with cat:

    cat file       |\
        program1   |\
        program2   |\
        ...

If you use a redirection, since the command does not start with a pipe the symmetry is broken.

Redirections at the start of the line are fun. I have an alias

    alias null='>/dev/null 2>/dev/null'

this allows to run GUI programs without cluttering the terminal with useless GTK/QT warnings:

    null evince file.pdf

Pro tip, if a line ends in a | you don't need a trailing backslash. The same is true if a line ends in || or && as those all imply continuation.

Edit:

    cat file       |
        program1   |
        program2   |
        ...

wow, that's great. Now what I miss is to be able to put comments after each such line.

I just tested it and, in bash at least, it actually works fine.

    echo foo | # echoing foo
        tr 'a-z' 'A-Z'
    FOO

this is incredible, I had already given up on this, and the solution was in front of my eyes the whole time! You have just greatly enhanced the elegance of several scripts in my lab.

Wow. Thank you for explaining this! I'd never understood why `cat` was called useless when (so far as I then knew) there was no other way to "start a left-to-right pipe by reading from a file" (other than the aforementioned `grep <filename> *`). This helps!

There's a natural workflow that tends to get ignored in these discussions: when you're not sure of all the details of the pipeline yet and your file is big enough to slow you down.

I typically start with (say) `head file | grep '2020'`. Once it does what I want I move to the next step, and so on until it's done. At that point, and having chained 5-6 commands, replacing `head` with `cat` is faster and less likely to break due to me putting the '<' in the wrong place. The simplicity and extra peace of mind is well worth an extra process IMHO.

Why always start with cat? Not using cat when you don’t need to means less typing, more efficient and mor robust code. Why use it if you don’t need to?

It's easier to change the start of a chain that starts with cat than if you're passing a filename into your first program. Even though it's _technically_ misuse, cat can improve composability.

In many situations it's quicker to just rely on muscle memory than coming up with the most efficient way to read a few 50kB files.

It's a good thing to be aware of the differences when needed, but often the execution speed is not the reason for writing a bash script.

I don’t think efficiency matters much in this case, but more robust and concise code is better. Most commands either take a file as a unnamed argument or you can just do something like <filename. But I agree, there may be commands where passing the file name is awkward (eg. jq)

I often prefer it in scripts for easier parsing later.

cat file.txt | somemonstrousoneliner

immediately tells me it's reading file.txt and doing something with the contents.

Burying the filename deeper in the string makes it harder to figure that out.

Reply on news.ycombinator.com