Cat without cat on the commandline (2020) | Hacker News Reader

Cat without cat on the commandline (2020)

jarv.org

25 pointszoidb20 comments

The main purpose of `cat` is not to print a single file to stdout but to conCATenate files to stdout [0]. Of course if I have a single file it's printed alone. Just here to say that `cat` is not a synonym of `print`, but nowadays it's "cat FILE" everywhere. Even in APIs... [1] (Compact and aligned text? XD)

[0] https://www.man7.org/linux/man-pages/man1/cat.1.html [1] https://www.elastic.co/guide/en/elasticsearch/reference/curr...

Yes and what I want to do is concatenate 1 file to stdout

And you don't want to use a pager because you know the file is shorter than one screen?

I have infinite scrollback and ⌘F

pagers are sometimes more of a burden than a help. If a file is relatively short, the terminal's scrollback may be sufficient to navigate the content. A pager may not cooperate well with the terminal's UI for scrolling, and may even mess up scrollback history. And, depending on configuration, may clear the screen when it's closed against the user's wishes.

Yes, there may be flags you can throw on them to make them behave the way you want, but those flags need to be remembered. `cat` is certainly shorter to type and easier to remember than `less -X`

What about syntax highlighting? If you're only interested in viewing the file anyway, there's a decent chance that would improve your experience.

I do accept that `cat file` is not a problem, but it's interesting to discuss alternatives anyway!

Try using a pager like more, which works on dumb terminals.

Shell scripting is one of those places where readability is king, and premature optimization is the devil.

Yes, there are multiple ways to get by without cat. Are they as obvious to understand? If not, what are we doing?

Shell scripting isn't meant for performance but composability. If you're fighting me over micro optimizations, I'm just going to rewrite it in a proper language and 100x its performance. But then it's lost its readability and it's no longer editable.

Balance, like most things in life.

At a certain point, it's not a problem with readability but that the reader doesn't actually know the language.

Is it a readability problem if someone is confused about foreach loops in Java, or perhaps we should expect the person to actually learn the language they are using?

Input redirection is a fundamental shell language feature.

Related: https://github.com/wader/catgolf (might not be completely serious)

Took me a bit to figure out a nice way to do this in the `fish` shell. I think it's `string collect < file.txt`.

The useful use of cat

https://news.ycombinator.com/item?id=41894933

If I didn't have manpages or the option to google I'd probably just use head or tail after doing 'wc -l' to determine line count.

head filename -n `wc -l filename`

In most cases you could simply use a huge number of lines like

  head filename -n 1000000000

or use the "inverse mode". Head and tail can print all but the first/last n lines (I just have trouble to remember without man page the syntax and which does what). So those are more "cat equivalents":

  head -n-0 filename
  tail -n+0 filename

PS: for your wc example you could actually do just

  head -n $(wc -l filename)

because `wc` will print the number of lines and the filename. (does not work with spaces)

On what kind of Linux system do you get a shell but don't have access to `cat`?

A damaged one you're trying to recover :)

Hardened container images

the read/echo loop will not handle nulls

the command substitution will mangle ending newlines

Reply on news.ycombinator.com