Chrome probably spawned two processes when I cmd+clicked this into a new tab. It really doesn't matter.

Program A might accept a file as the last positional arg. Program B might accept it as a named arg, where the name/flag could be anything from --input or -f or --file etc.

But a program will read from STDIN, which all good unix programs do, then piping cat into it works every time. I can write the cat foo.txt part before I even know what command I'm piping it into.

You can start your pipeline with a file redirection: " <input_file prog1 | prog2 | prog3 | ... | progN >output_file".

I've probably lost 10ms * 1E5 of my life from the extra PID. But, probably would lose more in the context switch.

    cat expected.1376| sed '1,4d' | rg '(\t\d)\t.*' --replace '$1' | column -ts $'\t'

You know what? I'll tell you another thing I do that's similar:

    SELECT * FROM whatever WHERE true
        AND last_modified > 123
        AND otherfield NOT NULL

"Oh no, it spawns another process!!" Again, nobody cares.

"< file.txt somecommand | othercommand | anothercommand"

There is never any need for "cat".

When such a pipeline is used repeatedly in a script, the time for executing the redundant process "cat" can easily add up to a noticeable delay.

> "cat" can easily add up to a noticeable delay.

If you have a slow script, you will have more useful places to optimize than removing calls to cat.

  cat file | wc -l            => wc -l < file
  cat file | head -n 5        => head -n 5 file
  cat file | awk '{print $1}' => awk '{print $1}' file
  cat file | sort             => sort file

  cat file | wc -l            => <file wc -l
  cat file | head -n 5        => <file head -n 5
  cat file | awk '{print $1}' => <file awk '{print $1}'
  cat file | sort             => <file sort

  cat file > /dev/null 2>&1

  2>&1 >/dev/null cat file

    0: stdin  -> stdin  -> stdin
    1: stdout -> stdout -> /dev/null
    2: stderr -> stdout -> stdout

    0: stdin  -> stdin     -> stdin
    1: stdout -> /dev/null -> /dev/null
    2: stderr -> stderr    -> /dev/null

It does not yield the "same output", and here is why: if you cause your command to actually produce output on stderr (fd 2) it will appear as terminal output, because you have actually succeeded in "redirecting" stderr to wherever stdout (fd 1) was pointing initially.

And that is because fish isn't POSIX-compliant. It's like when translating languages, some words are cognate, but some are "false friends" and while they look the same, they don't mean the same thing. So when using redirections in fish, the rules may be similar up to a point, but only up to a point.

I do agree that the performance cost of using "cat" is negligible, but sometimes it's instructive to learn techniques that improve efficiency. Personally, I write a lot of bash scripts and I tend to avoid using external programs when I can use built-ins e.g. "printf" instead of "echo", though avoiding "echo" is recommended anyway due to its lack of POSIX compliance.

Personally, when I'm exploring, I build a command line iteratively. Cat the file to see the content, pipe to grep to get the lines I want, sed/awk/cut/etc to finagle from there.

     VSZ   RSS    SZ CMD
    3252  1608   813 /bin/cat

Now for firefox:

        VSZ    RSS     SZ CMD
    3472212 395968 868053 /usr/lib64/firefox/firefox

(who gives even a single shit, my god)

This adds the joy of doing only what is really needed, without extraneous effort.

Moreover, in this way the start of a pipeline becomes symmetrical to its end, which frequently is an output redirection.

cmd1 | cmd2 | cmd3 | ... | cmdn

Edit: for context my home router is a TP Link and for some reason it has IPv6 disabled completely and I'm too scared to enable it.

When you're building a pipeline, putting cat first can often be quite convenient. Essentially, it's more composable: it defines the input to the pipeline without committing to a specific tool. For example, you can up-arrow in the shell and change the part after the pipe without having to skip back past the filename.

In fact if you don't start with cat, it's possible you're more of a script kiddie than a software developer.

http://catb.org/jargon/html/U/UUOC.html

Admittedly its taken me a long time to remember that the file is the last argument to grep, when so many other commands its the first. I'd guess common abuse is due to being easier to type cat x | than to dig up the man page

`alt + .` is much more versatile. You can use it to cycle through and insert the last arguments of previous commands.

I guess the file is usually the last argument because it's the one that can be omitted.

Anyway, the reason I use useless cat is because when I'm working with large files, it starts with head, not cat, or tail, and then only after I've built the pipeline do I use cat to process the whole file.

- various HostGator employees, c. 2011

< file grep abc