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'
I was figuring shit out along the way and it'd be pretty annoying to adjust which command gets the filename throughout that process.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
Always bugged me that you say WHERE for the first one and AND thereafter, so if I'm poking around the database trying to create actionable insights for key stakeholders at the speed of business just as I was above with the text file, I like to be able to futz and delete/add clauses as I see fit just as I do pipeline stages."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.
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.
(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.
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.
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
Do this instead: 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
The front-cat abuse is all about the order. The effective solution needs to keep the relative order of arguments. cat file > /dev/null 2>&1
work as intended. 2>&1 >/dev/null cat file
appears to yield the same output. So i wonder where the not "order-independent" chimes in. 0: stdin -> stdin -> stdin
1: stdout -> stdout -> /dev/null
2: stderr -> stdout -> stdout
When you flip the order, `> /dev/null 2>&1` moves FD1 to /dev/null first, and then FD2 to the contents FD1 (/dev/null again), so you discard both errors and standard output: 0: stdin -> stdin -> stdin
1: stdout -> /dev/null -> /dev/null
2: stderr -> stderr -> /dev/null
In your example, `cat file` is unlikely to produce any errors, which is why you're not seeing a difference.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.
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.
Take a look at the start of a file:
head file
Filter for things: head file | grep ...
Reformat, remove unwanted stuff, etc.: head file | grep ... | sed ...
Do things or dry run echo based on each line: head file | grep ... | sed ... | while read a; do ...; done
It all looks good so we change head to cat to run it on the whole file: cat file | grep ... | sed ... | while read a; do... ; done
Yes you can technically change "head file |" to "< file" but why bother? That's changes in two places and navigating between them instead of just <alt-d> cat.Same is true for other workflows. E.g. if you start with one of these supposedly better commands like "wc -l < file" (why isn't that just "wc -l file"?):
wc -l < file
Oh wait, we don't want every line, just ones matching a pattern. We could change it to wc -l <(grep ... file)
or grep -c ... file
which are both more work than just adding to an existing cat-based pipeline, where we just replace cat with "grep ...": grep ... file | wc -l
If we need to also match another pattern or whatever this pipeline approach is better then too. VSZ RSS SZ CMD
3252 1608 813 /bin/cat
To me there are far more things to worry about than cat. How about your multi-gig browser for one ?Now for firefox:
VSZ RSS SZ CMD
3472212 395968 868053 /usr/lib64/firefox/firefox
Maybe people should be looking at that ? I will not even get into modern Linux Desktops :)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.
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.
cat file | grep thingone
cat file | grep thingtwo
Vs grep thingone file
grep thingtwo file