I often use cat to print very short files to the console, the files in /proc and /sys are very good candidates. This way I can see the content of multiple files simultaneously.
–
FeuermurmelSep 16 '14 at 7:06

I usually use cat when I need to type a command based on something in the file. cat is more convenient since you can see the file (if it's small) while you have access to the shell prompt. It also allows for pipe lining.

Upvoted. I do this regularly. If I want to grep a file multiple time for different search terms, this is easier. grep wants grep [search term] [filename] Therefore, it's more of a pain to edit the search term if I am using the terminal history. By piping to grep, the search term is the last thing on the line, and easier to edit.
–
Fake NameSep 28 '11 at 3:39

9

You can still have the ordering you want without using cat: < [filename] grep [search term] and < filename tail -n 1000 | grep pattern. Redirection can go pretty much anywhere on a command line.
–
camhSep 28 '11 at 7:18

Although both commands allow you to view the content of a file, their original purposes are quite different.

less extends the capabilities of more. The latter was created to view the content of a file one screenful at a time. less adds features such as backward movements and better memory management (no need to read the entire file before being able to see the first lines).

cat concatenates files and prints the result on the standard output. If you provide only one file, you will see the content of that file. It becomes 'powerful' when you provide multiple files. A good example is the combination of split and cat. The first command will divide a large file in small portions. The second one will then concatenate the small portions into a single file.

Back to your question, cat would be preferred in an autonomous script requiring files to be read entirely (or concatenated) without interaction. In terms of file viewing, I think it's more a question of taste.

I know grep supports filenames, but If you are grepping the same file for different search terms, editing a command where the search term is the last thing on the line is easier then having to ctrl+arrow-key back through the line.

If you use zsh as a shell, you can set it up so that $<filename (where $ is the prompt) invokes $PAGER with stdin connected to filename. That is even fewer characters to type than cat.
–
Kevin CathcartSep 28 '11 at 17:33

I guess, because of the poularity of Unix variants now, many people don't have to administer their systems (with a vengence). When things go tits-up you might just be able to reboot and enter your system in what is called a restricted environment.

You get a command line and access to a small set of what is deemed useful commands that are small and usually statically linked. You might get vi as an editor or even the smaller ed, but not emacs or vim. You would get cat, but not less. The idea is to give you enough tools to repair your system without taking too much resources as those resources may be incorrectly configured, or all used up. the less command onder those circumstances is superfluous.

There can be an issue with privilege escalation, as within 'less' you can press 'v' to edit a file or '!' to send a shell command.

You might want to allow some users to view a file that can only be read by the superuser, but not allow those users to edit the file or to use superuser privileges in general. You could do this by editing '/etc/sudoers' to allow them to use 'sudo /bin/cat /etc/importantfile'. You wouldn't want to allow 'sudo /usr/bin/less /etc/importantfile', because they could use 'v' to edit the file, or use '!' to launch a shell with full superuser privileges.

Of course, the users could use 'sudo /bin/cat /etc/importantfile | less' and still use 'less', without the security risks.

I use less -FX, which makes less behave like cat when a file can be
displayed on one screen. From the less(1) manpage:

-F or --quit-if-one-screen
Causes less to automatically exit if the entire file can be dis-
played on the first screen.
-X or --no-init
Disables sending the termcap initialization and deinitialization
strings to the terminal. This is sometimes desirable if the
deinitialization string does something unnecessary, like clear-
ing the screen.

In terms of how to show the characters on the screen, less can do what cat can do; And much more.

But there is a very good reason to use cat for some cases:less is just too complex to throw it on very simple problems. I has so many options that it's hard to find the cat-related ones in the man page.

Want to show the tabs in a Makefile?

In man cat, the first option is -A.
The description is not helpful: -vET.
But the long option name sounds just right: --show-all.