Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The useful use of cat

mrmr.io

Post reply on HN
Print view View original

81–90 of 113 posts

Re: The useful use of cat

#81

Post by MathMonkeyMan »

globular-toast wrote: post #35
codesnik wrote: post #27

if you prefer to use cat just to read your pipeline from left to right, you can just start your command with file redirection. It doesn't have to be at the end of the command. this works in bash too, but if you're using zsh, there're a couple of nice shortcuts on it's own works as more file and > file ... ... ^D allows you to put something into the file quickly without firing up the editor. Though > file will give yo…

If I saw It would give me pause. If I saw cat file | grep ... I would understand it instantly, as would any other Unix user. Therefore the latter is better code.

My coworker said the same thing. But now that you know, will it give you pause?

Shell has tricky and arcane corners that are best to avoid, but you still do better to know about them, lest they bite you (shellcheck helps).

I don't think that "I/O redirection can precede the command name" is particularly tricky or arcane.

What bothers me is that it doesn't work with loops:
The shell's grammar is quite a thing.

Re: The useful use of cat

#82

Post by MathMonkeyMan »

kortilla wrote: post #18
jchw wrote: post #10

Earlier quoted context omitted.

Yeah, there are still some edge cases where cat is useful, but more often than not I just begin the redirection. I reckon some don't realize you can put it at the beginning, which does sometimes feel more ergonomic in a pipeline.

A pipeline without pipes connecting is just a field of shit

IO redirection doesn't construct a pipe, but piping does.

    # Open foo.txt and use it as fd 0 in jq
Best thing would be a directed graph where each node is a process or a file. A process has at most one edge going into it (stdin) and at most two coming out (stdout and stderr). A file has exactly one edge touching it.

Hard to do in text, though. Would look like lisp.

Re: The useful use of cat

#83

Post by globular-toast »

crdrost wrote: post #62
globular-toast wrote: post #35

Earlier quoted context omitted.

If I saw It would give me pause. If I saw cat file | grep ... I would understand it instantly, as would any other Unix user. Therefore the latter is better code.

The problem is that according to this argument `cat` should never be used for the thing it was designed for, because if you use it with more than one argument, it would give most Unix users pause, but if you saw it with only one argument they would understand it instantly. The whole point of the "never use cat" Unix advice is a war between instrumentalism and design purism. Should things be known mostly for what they…

It is the thing it was designed for:

    CAT(1)

    concatenate [one or more] files and print on the standard output
A list of length one is still a list. It's best to write code that can handle lists of any size, not to write special cases that handle a fixed number of primitives.

You can swap `cat` for `zcat`, for example, and things still work in just the same way. This would be very awkward to do with input redirection.

Maybe using `cat` like this appeals to people with more of a functional programming exposure.

If we were going to completely change the shell behaviour I think `file > grep` makes more sense than `file | grep`.

Re: The useful use of cat

#85

Post by pbaam »

x3n0ph3n3 wrote: post #64
pbaam wrote: post #57

Earlier quoted context omitted.

The cat command can be omitted there, as tee reads from standard input by default, even if stdin points to a terminal. I was going to comment an actually useful (and unavoidable in bash) use of cat and ssh, which is to do do nothing with standard input and redirect it to a file: file' And you could just use scp, but I've found clients without scp and servers with the SFTP subsystem disabled.

I want do paste from my clipboard, not copy another file.

I know, it's intentionally unrelated. But if you read my first sentence, you can do what you are interested in without using cat.

  sudo tee somefile > /dev/null
And you will be able to paste from your clipboard or write anything you want. Without cat or piping.

Re: The useful use of cat

#86

Post by unnah »

sgarland wrote: post #44
yjftsjthsd-h wrote: post #12

Earlier quoted context omitted.

I'm not sure I have ever used tac for real. Could you give an example?

When you want to tail a file, but you want it in descending order and you’re not sure how much of it you want: tac file | less

I'll just stick with tail -f until they implement tac -f

Re: The useful use of cat

#87

Post by xelxebar »

kelnos wrote: post #26
wwalexander wrote: post #5

You can still just begin with <somefile instead of cat somefile |. Does it really matter? No, but I don’t think pointing out useful and concise built-ins is necessarily asinine.

Can you? In bash I end up with no input at all if I start the line with '<somefile'.

Ahem, try this: <file cat

Re: The useful use of cat

#88

Post by xelxebar »

Speaking of redirections... Here's another fut bit of lesser-known shell:

    f(){ cat;}
I.e. You can bind redirections to function definitions that end up applying at call time.

Re: The useful use of cat

#89

Post by cellularmitosis »

MathMonkeyMan wrote: post #81
globular-toast wrote: post #35

Earlier quoted context omitted.

If I saw It would give me pause. If I saw cat file | grep ... I would understand it instantly, as would any other Unix user. Therefore the latter is better code.

My coworker said the same thing. But now that you know, will it give you pause? Shell has tricky and arcane corners that are best to avoid, but you still do better to know about them, lest they bite you (shellcheck helps). I don't think that "I/O redirection can precede the command name" is particularly tricky or arcane. What bothers me is that it doesn't work with loops: The shell's grammar is quite a thing.

“Subsetting” a language is a useful practice. Consider the set of language features someone has to know in order to understand your code. If you can make that set smaller (without unreasonably sacrificing functionality), you lower the barrier to entry. More people can read your code.

The typical retort I hear is “but it’s just this one feature, how hard is it to learn just one feature?” But you’re only considering your favorite feature. To the casual code reader, it isn’t just that one feature, it’s everyone else’s favorite obscure feature as well.

Using cat makes your code readable to a wider audience. Using cat has real upside with no downside. Forcing your readers to learn more shell syntax has real downside with no practical upside.

Re: The useful use of cat

#90

Post by Lockal »

sim7c00 wrote: post #8

cat all the things. i cat | grep and im not ashamed of it! cat | less - why not.? its not going to melt my pc more or less if i cat | more | less...

You may miss some optimizations for cat | tail. And you can't --follow a cat, obviously!
Post reply on HN