Rendered at 03:25:28 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
jasongi 16 minutes ago [-]
The beauty of cat is that streams are the universal interface.
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.
fuzzybear3965 8 minutes ago [-]
This. Sometimes I want to see what I'm looking at and then (using that dump as a reference) follow up with a corresponding filter (| jq .key, or | tail -n 30). Sure, I could use less, but then I context switch on exit; no support from the scrollback buffer.
I've probably lost 10ms * 1E5 of my life from the extra PID. But, probably would lose more in the context switch.
internet2000 1 hours ago [-]
> Piping a single file through cat spawns an entire process whose only job is to copy bytes to a program that already knew how to read them.
Chrome probably spawned two processes when I cmd+clicked this into a new tab. It really doesn't matter.
MPSimmons 25 minutes ago [-]
Unless you're executing these commands in a loop over a large number of items, or the item itself is gargantuan, it's almost always harmless.
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.
floren 60 minutes ago [-]
if this wanton abuse of cat(1) doesn't stop, we're on track to run out of PIDs by 2031! Just because Unix makes it cheap and easy to fork doesn't mean you have to!
(who gives even a single shit, my god)
floralhangnail 6 minutes ago [-]
Is this a dig at IPv6?
copperx 29 minutes ago [-]
I like piping the output of cat and the mental image of one process feeding another. It's inconsequential, but it brings an epsilon of joy.
djtriptych 16 minutes ago [-]
same I just like monads lol. cat + pipe feels purer and has lower mental load for me, which dominates the efficiency of spawning an extra process for, typically, a few microseconds.
23 minutes ago [-]
petee 3 hours ago [-]
> Since 1995, occasional awards for UUOC have been given out, usually by Perl luminary Randal L. Schwartz
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
smelendez 1 hours ago [-]
And also typing cat x to get a quick look at the file, hitting up, then piping that into another command and taking a look, hitting up, piping that result into a third command etc.
js2 1 hours ago [-]
It's that way so that you can grep multiple files with a single pattern. It would be odd for the pattern to come after the file arguments. It also allows the files to be optional so that it can grep stdin.
soraminazuki 1 hours ago [-]
The redirection operator is consistent and requires less typing though.
I guess the file is usually the last argument because it's the one that can be omitted.
The front-cat abuse is all about the order. The effective solution needs to keep the relative order of arguments.
stouset 1 hours ago [-]
Or just use cat and spend your brainpower on interesting, useful, and/or worthwhile topics. It boggles my mind that anyone cares about this.
lifthrasiir 52 minutes ago [-]
Probably, but knowing that redirection operators can be freely moved within normal arguments [EDIT: thank
ButlerianJihad for pursuing me to make this more accurate] is useful.
ButlerianJihad 43 minutes ago [-]
They are actually not “order-independent”, and their L-R parsing/processing is why constructs such as
cat file > /dev/null 2>&1
work as intended.
ablob 31 minutes ago [-]
funny enough,
2>&1 >/dev/null cat file
appears to yield the same output. So i wonder where the not "order-independent" chimes in.
pdpi 10 minutes ago [-]
`2>&1` redirects FD2 to the current contents of FD1 (stdout), then `> /dev/null` redirects FD1 to /dev/null. That results in your errors going into stdout, and discarding regular output altogether:
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:
In your example, `cat file` is unlikely to produce any errors, which is why you're not seeing a difference.
isityettime 20 minutes ago [-]
All of this depends on your specific shell and its parser. Fish doesn't let you put redirections at the beginning like that (though I wish it did), while GNU Bash does.
ButlerianJihad 11 minutes ago [-]
fish is not POSIX-compatible, and not Bourne-compatible, so I don't see how that really matters at all. I used the rc shell from plan9 for quite a while, and I wouldn't expect its syntax rules to match, either!
ButlerianJihad 25 minutes ago [-]
You're absolutely wrong!
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.
ablob 1 minutes ago [-]
So what we've gathered from this interaction is that the relative order of redirection operators matters, but it doesn't matter where in the command they are placed apart from that.
antonvs 1 hours ago [-]
Presumably written by someone without much interactive shell experience.
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.
dminvs 1 hours ago [-]
"Don't be a catgrepper"
- various HostGator employees, c. 2011
jmclnx 1 hours ago [-]
In this day an age this is still making rounds ? So this is the memory usage of cat on my system:
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 ?
Maybe people should be looking at that ? I will not even get into modern Linux Desktops :)
Shadowmist 2 hours ago [-]
I’m going to keep doing it but wouldn’t mind it if my shell auto replaced it for me.
pyrolistical 1 hours ago [-]
I like putting the stdin before the command
< file grep abc
sprior 1 hours ago [-]
I raised eyebrows recently when I was working with someone and we needed to create a file and instead of starting an editor I did:
cat > filename
...
Ctrl-D
bonsai_spool 1 hours ago [-]
Why not touch or echo? No reason for an editor or cat
sprior 46 minutes ago [-]
For a one line file sure, but I was creating multiple lines.
stouset 59 minutes ago [-]
You can type the intended file contents as-is.
3 hours ago [-]
BugsJustFindMe 2 hours ago [-]
[flagged]
doubled112 1 hours ago [-]
Chances are the file stays the same and what Im grepping for changes, so after the first run, it was less work for me not needing to go back as far in the command
cat file | grep thingone
cat file | grep thingtwo
Vs
grep thingone file
grep thingtwo file
BugsJustFindMe 1 hours ago [-]
That's fine. It's fine to do the thing that brings you joy.
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.
I've probably lost 10ms * 1E5 of my life from the extra PID. But, probably would lose more in the context switch.
Chrome probably spawned two processes when I cmd+clicked this into a new tab. It really doesn't matter.
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)
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
I guess the file is usually the last argument because it's the one that can be omitted.
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.
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.
- various HostGator employees, c. 2011
Now for firefox:
Maybe people should be looking at that ? I will not even get into modern Linux Desktops :)< file grep abc