56

I used to use cat to view files. Then I learned that less is usually better, and is a must if the file is longer than a few dozen rows.

My question: Is there ever a reason to use cat instead of less? Is there any situation where cat is a better solution?

migrated from serverfault.com Sep 27 '11 at 20:37

This question came from our site for system and network administrators.

  • 17
    less and cat solve different problems and they are each better than the other in their own problem domain – David Heffernan Sep 28 '11 at 16:24
  • 2
    I only use cat to pipe it's output into less afterwards. – FUZxxl Sep 29 '11 at 19:02
  • 1
    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. – Feuermurmel Sep 16 '14 at 7:06

18 Answers 18

20

I personally prefer view for static content or tail -f for dynamic content.

This does not answer your question, though. There is a saying "why use more if you have less" ;-)

But there are cases where I prefer cat to less: I usually work with X11-windows. These windows have a scroll-buffer which can be set to some hundred lines.

Doing a cat for - let's say 200 lines and then using the mouse with the scroll-bar is more comfortable to me than using less in these cases.

  • 4
    By view you mean the usual vim -R, or you have something else with that name? – manatwork Sep 29 '11 at 6:55
  • No - just vi (or vim) in read-only-mode. CentOS sets that alias by default. This will not trigger HIDS when viewing a file in a secured directory. – Nils Sep 29 '11 at 20:32
  • 2
    less +F does what tail -f does. – legends2k Dec 31 '14 at 9:54
  • 1
    Actually, view is not an alias; it's a link (to vi or vim). vi looks at argv[0] when it starts (to see what name it was invoked under) and, if that is view or rview, it sets read-only mode (as if you had typed vim -R). – G-Man Sep 22 '16 at 3:54
90

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.

  • 4
    less always allows to search within the file, which cat does not. – Bernhard Aug 11 '13 at 6:30
  • @Bernhard: What about doing a grep on cat output? – user3527975 Nov 14 '17 at 21:50
23

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.

  • 3
    For one file, redirecting the standard input is also possible and often preferable. – AProgrammer Sep 28 '11 at 9:41
17
Is there any situation where cat is a better solution?

When you are dealing with more that one file and wish to concatenate them.

From the man page:

cat f - g
        Output f's contents, then standard input, then g's contents.
15

There are people who argue violently that the only purpose of cat is to concatenate files. For every other use, there is more (or less).

But this fails to take into account one quite important fact: cat is one character less to type. I use those commands so often that one character less is a no-brainer.

Another reason is when you want to create a file. I often copy-and-paste text from the web into a file like this (command prompt shown):

$ cat > filename
<Cmd-V>
<Ctrl-D>
$

That is, I open a file filename for write access, paste the content and close the stream by pressing Ctrl-D. Neither less nor more can do that, and it’s faster than opening an editor.

  • 4
    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 Cathcart Sep 28 '11 at 17:33
  • @Kevin Nice to know but I’m a bash user. – Konrad Rudolph Sep 28 '11 at 17:34
  • 2
    On Mac OS X, I use pbpaste > filename, and I believe X has something similar. I do still use cat for quick file creation, just not for pasting. – cobbal Sep 29 '11 at 17:34
  • @cobbal Hehe, I never thought of that even though I use pbcopy / pbpaste for other purposes. – Konrad Rudolph Sep 29 '11 at 18:15
  • 1
    It's actually two characters less - you have to press q to exit less :D – Martin von Wittich Sep 15 '13 at 18:46
9

Sometimes you don't want the pagination that less does and just want the complete file so you'd use cat.

4

I use cat to grep (multiple) files.

cat <filename1> [<filename2> <filename3>] | grep -i "string of interest"

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.

4

cat can be used to concat several binary files into one big one:

cat data.001 data.002 data.003 > bigdata.dat
3

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.
2

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.

2

And less is not pre-installed on all GNU/Linux distributions. (eg. Gentoo) cat is everywhere, probably.

2

The cat stays on the screen. Everything less disapears.

Clarified by/for Volker Siegel:

The output of cat stays on the screen. Everything shown by less disapears after closing.

1

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.

1

The two are different. less is a non-standard pager (more is the standard one), used for viewing text, while cat is a standard utility, used for concatenating any type and number of data streams into one.

They might appear to do the same thing under some circumstances, but then again, so does other utilities.

0

For convenience. cat have 3 characters while more/less have 4 characters. And typing cat only require your left hand only.

  • 1
    Why is only using your left hand an advantage? I don't use the mouse on the terminal... – Bernhard Aug 17 '13 at 9:09
0

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.

And cat -A Makefile does what I need.


Now, go find that for less.

0

Both 'less' and 'more' will work exactly like 'cat' if the output is not a terminal (tty), as to pipes and files, they will both revert to no pagination.

I think it's safe to say that 'cat' is always present on any Unix-type system you will ever find. The presence of 'less' and/or 'more' on any system is less predictable.

In scripts therefore, if you need only a non-pagination operation, 'cat' is sure to be present wherever your script is used on a Unix-type system.

  • 1
    Well, it's safe to assume that more will be available, seeing as it's mandated by the Single Unix Specification. – Kusalananda Dec 31 '16 at 12:53
  • Sadly, whilst it may be mandated like that, but in my experience it is not always present. It's worth noting that there are a number of Unix-like systems that don't claim to be Unix. I think one can be fairly confident that either a less or a more will be present, but I think one can't trust a particular one, nor that it's a 'true' implementation ... often one is aliased to the other, sometimes they're a minimal lightweight version. – user208007 Jan 1 '17 at 15:17
-1

Piping cat through grep is useful:

cat <filename> | grep -i "string of interest"
  • 4
    Not to mention that grep takes a filename as an argument, or you could use redirection. The pipe is expensive. – Chris Down Sep 27 '11 at 21:06
  • 24
    Congratulations, you win a 'useless use of cat' award! – ThatGraemeGuy Sep 27 '11 at 21:14
  • 4
    @TimKennedy - "when you've got less" is in the question title... – Chris Down Sep 27 '11 at 21:35
  • 5
    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 Name Sep 28 '11 at 3:39
  • 10
    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. – camh Sep 28 '11 at 7:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.