Yes, but it shows information about recent/current logins and requires access a file called wtmp (or something like that, off the top of my head), and that requires privileged access.

My usual use case where I mix it up is looking at a log file and and I just want to see the last few entries. So my brain 🧠 tells my fingers to type “last logfile”, and when I get the permission message it tells my mouth to go, “Doh!”.

Reverse chronological order, mostly

tac log.txt |head # would give you newest first

no good for sort because sort already supports -r

no need it for tail on large files because tail already skips to the end.

I do a lot of impromptu bash to sus crap out of logs.

when you’re balls deep in

cat log|grep -v foo| rev|cut -f 1-3 -d \ | |rev

Sometimes tac comes in clutch.

man bat | bat

it won’t… do anything

it’ll wait for you to type ten lines (the default for head without arguments), buffer them (bc tail must buffer its input), then spit them back at you, and exit

• head takes the first N lines of its input (if -n <number> is not specified, the default is 10 lines, and default reading from stdin, which in this case is your terminal) and prints them to its stdout (which thanks to the pipe, goes directly to cat’s stdin), then signals end-of-file.
• cat accepts any number of filenames and conCATenates them (hence the name), writing their contents one after the other to stdout. with only one file as argument (the most common case in practice) it will simply write that file’s contents to stdout. with no arguments (as in this case) it will simply copy everything from its stdin (in this case head’s stdout) to its stdout (in this case tail’s stdin). the cat command could be completely omitted from this invocation (leaving simply head | tail) and it would work exactly the same.
• tail reads its entire input (like head, it defaults to reading from stdin unless a filename is specified) and buffers it, then, when the end of the file is reached, it prints the last N lines is read (again defaulting to 10 unless -n <number> is specified) to stdout (in this case your terminal).

put all together, head will wait for you to type a line, then will pass it on to cat, which will then immediately pass it on to tail, which will add it to a buffer and wait for another line. rinse and repeat until you have typed 10 lines, and then head will exit and the pipe between it and cat will close. cat, noticing the closed pipe, will exit in turn, causing the pipe between it and tail to close. tail, seeing an end of file signal on its input pipe, will cough up the last 10 lines in its buffer and then exit. since head only sent it 10 lines, this is the entirety of its input. so it will spit back everything you typed.

If you press Ctrl+D to send head an end-of-file signal before you have typed 10 lines, head will exit immediately, causing cat to exit, causing tail to output everything it had in its buffer so far.

Put suspicious cats into sandboxes until it’s proven that they are crewmates.

whatis cat?

But wheres the manual??

it’s just a natural start to a pipeline

It wouldn’t be at the end, since you’d still be piping into program

program <file | grep | cut

I don’t know why anybody would disagree with this. It’s a very clean way of putting it.

< file.txt grep thing also works.

awww what’s a cat without a head and a tail?

Admittedly I still use cat for this.

This also works too, but it’s more verbose:

echo "$(<foo.txt)"

It’s mentioned in the Bash man pages:

The command substitution $(cat file) can be replaced by the equivalent but faster $(< file).

EDIT: I was just informed that simply <foo.txt works too.

You can use less. There are also specialized ones for that purpose like bat.

If it’s really long, I use less , because it breaks it up into navigable pages instead of filling your entire buffer. :)

Never knew about just using < though! Cool!

So close! you have to do cat < foo.txt :-) (/s)

I know, but I just wanted to mention this since a lot of new Linux users end up using cat this way :)