←back to thread

2039 points Gadiguibou | 1 comments | | HN request time: 0.354s | source
Show context
klausa ◴[] No.36491947[source]
`pbcopy` and `pbpaste` are one of my most-loved in the list.

Dealing with some minified json, switching to iTerm, doing `pbpaste | json_pp | pbcopy` and having a clean output is _so_ nice.

replies(28): >>36492008 #>>36492015 #>>36492028 #>>36492101 #>>36492108 #>>36492229 #>>36492265 #>>36492890 #>>36492953 #>>36493037 #>>36493127 #>>36493336 #>>36493457 #>>36493802 #>>36494023 #>>36494242 #>>36494325 #>>36495379 #>>36495894 #>>36496866 #>>36497033 #>>36497293 #>>36497589 #>>36497973 #>>36498181 #>>36498558 #>>36498586 #>>36535798 #
omginternets ◴[] No.36492265[source]
If I had a nickel for each `cat foo.json | jq | pbcopy`, I'd be a rich man :)
replies(1): >>36492862 #
maleldil ◴[] No.36492862[source]
That's a useless use of cat. You can use `jq . foo.json | pbcopy` or `jq < foo.json | pbcopy`.
replies(6): >>36492960 #>>36493144 #>>36493370 #>>36494558 #>>36495101 #>>36495918 #
nicky0 ◴[] No.36493144[source]
In what way do you see those alternatives as superior?
replies(3): >>36493372 #>>36494926 #>>36497774 #
1. gdavisson ◴[] No.36497774[source]
It usually doesn't matter much, but there are some situations where it can matter a lot. For one thing, you can't use seek() on a pipe, so e.g. `cat bigfile | tail` has to read through the entire file to find the end, but `tail bigfile` will read the file backward from the end, completely skipping the irrelevant beginning and middle. With `pv bigfile | whatever`, pv (which is basically a pipeline progress indicator) can tell how big file is and tell you how for through you are as a percentage; with `cat bigfile | pv | whatever`, it has no idea (unless you add a flag to tell it). Also, `cat bigfile | head` will end up killing cat with a SIGPIPE signal after head exits; if you're using something like "Unofficial bash strict mode" [1], this will cause your script to exit prematurely.

Another sometimes-important difference is that if there are multiple input files, `somecommand file1 file2 file3` can tell what data is coming from which file; with `cat file1 file2 file3 | somecommand` they're all mashed together, and the program has no idea what's coming from where.

In general, though, I think it's mostly a matter of people's expertise level in using the shell. If you're a beginner, it makes sense to learn one very general way to do things (`cat |`), and use it everywhere. But as you gain expertise, you learn other ways of doing it, and will choose the best method for each specific situation. While `cat |` is usually an ok method to read from a file, it's almost never the best method, so expert shell users will almost never use it.

[1] http://redsymbol.net/articles/unofficial-bash-strict-mode/