Stop using tail -f (mostly) • Hacker News Board

Re: Stop using tail -f (mostly)

#91

Post by teraflop » Mon, Mar 30, 2015, 6:50 PM UTC

lgas wrote: post #89

toddkaufmann wrote: post #67

Earlier quoted context omitted.

Use '/' (search) to enter a regexp to match a pattern on that line, and it will be highlighted.

This has nothing to do with what is being discussed in this subthread.

Sure it does. If your log lines are distinct (e.g. they have timestamps or unique IDs) then you can use less's search highlighting to provide a visual marker for a specific line, similar to what you can do by manually inserting a bunch of blank lines on the console.

This trick doesn't work if your log file has a bunch of identical lines and you want to keep an eye on their rate, though.

Re: Stop using tail -f (mostly)

#92

Post by blueblob » Mon, Mar 30, 2015, 6:51 PM UTC

pjungwir wrote: post #72

bch wrote: post #31

Earlier quoted context omitted.

An example of some of the vi commands that less(1) has adopted. You can also: * page forward and backward, including using numeric prefixes to indicate a lineno or indicate "repeat 'n' times". * launch vi if less(1) is working on a file (versus (eg) stdout of some process) * search fwd/backward * start examining a new file w/o leaving less(1) * ...

Another less-vs-vi question: As a junior programmer I got chewed out by my IT department because I was examining a (production) log file in vi. The sysadmin told me I should use less (actually more---this was on Solaris in ~2001). To this day I only read log files with less, but I've never figured out his objection. Negatives to using vi I can imagine are: - I might write to the log file. That seems like a real worry…

I think your idea of `vi -R` or `vim -R` is a good idea. `less` uses less memory and may load faster but looking at logs for things like valgrind vim will give you syntax highlighting that I am not sure you can get with `less`.

Re: Stop using tail -f (mostly)

#93

Post by Yizahi » Mon, Mar 30, 2015, 6:51 PM UTC

jetpks wrote: post #54

If you're using a modern terminal with scrollback, you already have the ability to pause, and scroll back. # tail -f busy.log ctrl+s # Stops flow of output. pgup/pgdn for navigation # fn+up/dn for OS X users ctrl+q # Continues flow. No need to reinvent the wheel, the functionality you want is probably built into the tools you're already using.

But it won't show me old parts of the log and I usually want this.

Re: Stop using tail -f (mostly)

#94

Post by haberman » Mon, Mar 30, 2015, 6:55 PM UTC

spatz wrote: post #27

The problem is that less +F polls every second while tail -f uses inotify, which is both more efficient and responds faster to change.

I always thought it was such a shame that you couldn't use plain poll() for this. poll()-ing on a read fd at EOF for a regular file should work like poll()-ing a network socket.

Re: Stop using tail -f (mostly)

#95

Post by pearjuice » Mon, Mar 30, 2015, 6:57 PM UTC

Stop using [commonly accepted, proven method] and use [obscure alternative]

Textbook HN hit.

Re: Stop using tail -f (mostly)

#96

Post by reidrac » Mon, Mar 30, 2015, 7:02 PM UTC

Not convinced, still like tail -f because you can hit enter a couple of times and there you are... a nice visual mark to wait for new data without getting confused by existing content.

All this in my humble opinion. less is useful and I may use F to wait for data if I was looking for something in old logs, but for new data I still like tail -f :)

Re: Stop using tail -f (mostly)

#97

Post by prydonius » Mon, Mar 30, 2015, 7:04 PM UTC

I was interested in the significance of the plus for this flag. If anyone else was curious: from the manual, the + flag is for initial commands to less, so this is equivalent to running less and typing F.

Re: Stop using tail -f (mostly)

#98

Post by alinspired » Mon, Mar 30, 2015, 7:04 PM UTC

pimlottc wrote: post #15

I was introduced to less +F a while ago and it is quite nice, but there is one simple "feature" of tail -f that I miss quite a lot: being able 'mark' the log with gaps by hitting enter a few times. This is especially handy when you have to first load a page or warm up the app before performing the operation you're interested in watching, letting you separate the earlier output from the lines generated by what you're…

If you're using screen/tmux as myself, tail -f remains a good option, as you can enter gaps or search, or do 1000 more things as compared to plain terminal session

Re: Stop using tail -f (mostly)

#99

Post by agopaul » Mon, Mar 30, 2015, 7:13 PM UTC

For semi-large file (1/2GB+) less takes seconds if not minutes to count the number of lines (it read the whole file) so you can navigate and search across the file. In that cases tail -f and grep are still way faster than less, though less is a handier tool

Re: Stop using tail -f (mostly)

#100

Post by laumars » Mon, Mar 30, 2015, 7:13 PM UTC

> We all have been there: You are watching a file with tail -f, and then you need to search for something in this file, or just navigate up and down. Now you need to exit tail (or open a new shell), and ack this file or open it with vim to find what you are looking for. After that, you run tail again to continue watching the file. There's no need to do that when you are using less.

There's also no need to do that if you're running tmux, screen or have navigation tools baked into your terminal emulator.

Not that I'm trying to dismiss the effectiveness for +F for those inclined, but as the author acknowledged, +F also comes with some usability issues that -f does not (namely working with multiple files, and piping output into grep et al). Plus learning to navigate though terminal history is a useful skill to have in other situations anyway, and utilities like tmux are actually a very handy tool to use for a whole plethora of additional reasons too.

So kudos to the author for his recommendation and providing helpful write ups to future sysadmins, but I'm inclined disagree with him and instead recommend people stick with -f and learn tmux instead.