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)
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`
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.
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)
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?
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!
I have infinite scrollback and ⌘F
Related:
The useful use of cat
https://news.ycombinator.com/item?id=41894933
Related: https://github.com/wader/catgolf (might not be completely serious)
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.
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`.
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
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": PS: for your wc example you could actually do just because `wc` will print the number of lines and the filename. (does not work with spaces)the read/echo loop will not handle nulls
the command substitution will mangle ending newlines
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
[flagged]
This sort of meta is not really on topic, if you think there's abuse or some other problem you can mail hn@ycombinator.com and tell/ask them.
the same here XD