
Useless Use of Cat Award - shawndumas
http://partmaps.org/era/unix/award.html
======
kylec
Mentally, I think of most Unix utilities as operating on STDIN and producing
STDOUT. Therefore, to get the lines from a file into STDIN, I usually cat it.
It's pretty common for me to write something like:

    
    
        cat file | grep xyz
    

Of course, this is completely unnecessary and a "waste" of using cat, as grep
accepts as input a file or list of files to operate on, as do many other
utilities. However, I don't care. It's additional mental clutter to have to
remember the way to specify input from a file in addition to stdin when I know
I can always cat the file and pipe it to whatever command I want.

~~~
gav
As an alternative, you can always rewrite:

    
    
       cat file | grep xyz
    

To:

    
    
        <file grep xyz

~~~
e12e
No? Maybe you meant "grep xyz <file" ? In what shell does your line accomplish
the same thing?

[edit: Ah, I had an extra pipe in there. "<file command args" does indeed work
--- "<file | command args" does not]

~~~
kps
>In what shell does your line accomplish the same thing?

Any descended from or cloning sh, or csh, or rc… i.e. pretty much all of them.

------
brokenparser
Fuck Google for the link rot, everything that points to Deja News is now
useless. When will they start remembering their own corporate motto?

------
alexkus
My favourite seemingly-useless-but-actually-not-useless use of cat:-

    
    
        ls | cat

~~~
pdw
Or just

    
    
        ls -1
    

(that's a digit one)

~~~
alexkus
Ah, but with the --color=auto option on ls (which I have set in my aliases)
there's a difference between "ls -1" and "ls | cat"

Indeed there's even a difference between "ls -1" and "ls -1 | cat" if
"\--color=auto" is specified.

------
joshbaptiste
Yep, I see too many senior people violate UUOC/UUOG ie..

    
    
      cat file | grep bar | awk '{ print $1 }' | sort | uniq
    

which can be

    
    
      awk '/bar/ { print $1 | "sort -u"}' file
    

The best resource if you really want to be a better shell citizen (assuming
you use Bash) overall is #bash on irc.freenode.net and Greg's bash wiki.

[http://mywiki.wooledge.org/BashFAQ](http://mywiki.wooledge.org/BashFAQ)

Honorable mention also for #awk on irc.freenode.net also which has taught me a
lot.

~~~
clicks
I would still use the former.

Chances are, I'm not going to remember awk's somewhat weird, more unfamiliar
syntax -- everyone knows about cat, everyone knows about piping, those two go
very well together.

Using cat with pipes typically linearizes $x operation in our minds, it makes
it easier to come up with solutions, and makes it easier to change them as
modification is needed.

~~~
maw
_Using cat with pipes typically linearizes $x operation in our minds, it makes
it easier to come up with solutions, and makes it easier to change them as
modification is needed._

Yes, definitely. Also it's easier to build up from simple to more complicated
pipelines that way, testing whether each iteration does what you expect it to.

------
sleepydog
The "for f in `ls * `; do" example is actually not useless. It has the quality
that the loop will not run if there are no files, because ls produces no
output. Compare:

    
    
        $ for i in `ls * 2>/dev/null`
        do
            cat $i
        done
        
        $
        $ for i in *
        do
            cat $i
        done
        cat: *: No such file or directory
    

Imagine that instead of cat we have a large, complex, expensive loop and don't
want to pass a useless '*' to it if we can avoid it.

------
emhart
I felt painfully ignorant when I realized this was nothing to do with felines.

------
salmonellaeater
Another handy bit of syntax:

    
    
      $ command-name 2>&1 | less
    

This combines standard out and standard error into one stream so you can read
all the output in less [1]. Piping just standard out leads to stray error
lines popping up on the screen while less is running, and they aren't kept in
less's buffer so you lose track of them.

[1] [http://www.cyberciti.biz/faq/redirecting-stderr-to-
stdout/](http://www.cyberciti.biz/faq/redirecting-stderr-to-stdout/)

~~~
kbenson
Be careful when redirecting STDERR to STDOUT if yo uare also planning to
redirect STDOUT to a file. The order in which things are done affects the
outcome. These are not the same:

    
    
      # Redirect STDOUT to file, and STDERR to file
      command >/tmp/command.out 2>&1
      
      # Redirect STDOUT to file, and STDERR to screen (as STDOUT)
      command 2>&1 >/tmp/command.out
    

The important thing to remember is that 2>&1 is redirecting to what STDOUT is
_currently pointing to_ , not redirecting to STDOUT itself.

~~~
TorKlingberg
Recent version of bash support the (much nicer) csh syntax:

    
    
      command >& /tmp/command.out

~~~
kbenson
I wanted to mention that in the original post, but I can never remember the
syntax and was rushed. :(

------
dimitar
_The fact that the same thread ( "but but but, I think it's cleaner / nicer /
not that much of a waste / my privelege to waste processes!") springs up
virtually every time the Award is posted is also Ancient Usenet Tradition._

------
bcoates
I will accept UUOC awards only from people who never use rsync when tar or cp
will do.

------
lowmagnet
Though I've read this before, I've never picked up on the fact that you can
do:

> <file command

It makes sense because the first statement is really saying "set up an input
pipe" and not "This points at the command to my left."

------
16s

        cat file | grep string
    

It's a _gratuitous_ use of cat, it's not useless.

 _gratuitous - uncalled for; lacking good reason; unwarranted_

    
    
        grep string file
    

Is all you need.

------
otikik
Useless Use of Shell Award

When there are perfectly valid directives in your language, don't just shell
out. We ruby people do this too often.

------
skylan_q
Apparently, everything you do in bash is useless unless you're playing bash
golf. Nevermind the fact that the commands still output what you want.

