[jfb]

tsort. It's pointless until you need it, but when you need it, it's totally awesome.

less. Overkill, but SO MUCH BETTER THAN tail -f. Seriously. You can toggle "follow mode" without losing your place in the incoming stream.

[Florin_Andrei]

> less. Overkill, but SO MUCH BETTER THAN tail -f. Seriously.

If you do this on my servers, I am going to find you, and then I am going to kill... um... your process.

less with SHIFT-F takes a whole CPU core to run on a busy log file. tail -f takes almost nothing to run. Now combine that information with the reality of a whole bunch of devs who don't know it or don't care about it. :(

[alexkus]

I prefer:-

    tail --follow=filename

to:

    tail -f filename

The former will spot inode changes and reopen the filename if the file wraps (or has something else done to it to change its inode). The latter will just sit there seeing no new input in such cases.

[mje__]

multitail[1] is also really nice for following multiple log files. It can do highlighting of lines based on regex's, and has built-in highlighting of a wide variety of log formats

[1] http://www.vanheusden.com/multitail/features.php

[jlgreco]

Does anybody know if there is a good standalone regex highlighter? I usually use `ack --passthru`, but that has always seemed a tad.. overkillish to me.

[cjg_]

Hm, can you start at the end of file without reading the entire file with less? Use case is tailing large logs.

[ralph]

Yes, either type G when presented with the top of the file or pass +G on the command line. It will then read all the intervening file to calculate the line numbers, and tells you it's doing this and to interrupt it to stop. To prevent it doing this in the first place use the -n option.

"less -n huge_file" and then G only reads the start and end of the file. Type G again to move to the latest end of the file if it's growing.

[jfb]

Yes. It is CPU intensive (see auntie post above).