Huge caveat: "less +F" does not work with multiple files.
Yes, this is mentioned in the post, but I feel it is so big it would have deserved large, bold letters.
Stop using tail -f (mostly)
11–20 of 211 posts
Re: Stop using tail -f (mostly)
#12I use tail -f and when I need to search, I use iTerm's search (Cmd+F) which highlights matches and even supports regex. I also have an unlimited scroll buffer so I can just scroll up or down to get the context of a particular match.
This only works if what you are searching for has scrolled past since you started following. If you want to see other occurrences in the file you're out of luck. For example, let's say you are watching to see which error message is generated when something goes wrong, then you want to see when else that error message has been thrown.
Re: Stop using tail -f (mostly)
#13Or use multitail. It supports syntax highlighting, among other features: http://www.vanheusden.com/multitail/
multitail is great. I really cannot use command line utils that don't support colors/highlighting anymore. htop instead of top, etc. It just gives me much better visibility and readability. I'm surprised that so many non-color utils are still being used. It just feels so 1994 to me to stare at a white on black display. I guess there's nothing more slow moving and conservative than shell interfaces, thus articles like these that shame us into using different tools.
Personally, I'd love to see some hot young talent just do a 100% redo of the standard gnu utils from an interface perspective. Just go crazy with new interface and display ideas, novel presentation modes, novel navigation, etc while still maintaining backwards compatibility. I could see a big disruption here.
Re: Stop using tail -f (mostly)
#14Even when you don't want less +F, a good alternative to tail -f is tail -F. It survives log rotation, and the file being temporarily inaccessible: --retry keep trying to open a file even if it is inaccessible when tail starts or if it becomes inaccessible later; useful when follow- ing by name, i.e., with --follow=name -F same as --follow=name --retry
This is my standard now. Logs rotate all the time and it very convenient to have tail continue working without my intervention.
Re: Stop using tail -f (mostly)
#15I 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 testing.
With less, you have to keep track of the current position by timestamp or other unique message, and it's easy to lose your place when the output starts streaming in. With tail, you only need a moment to mark your spot and then it's visually distinct even as more message come in.
Re: Stop using tail -f (mostly)
#16This _almost_ touches on the useful part of this: If you search in less and then put it in follow mode, it continues to highlight the search terms. This is very useful for trapping an exception or webcall in the wild. The downside: less buffers and tail -f prints directly. On a slow printing log this can cause events to show up slowly, and can cause performance issues on a fast moving log. If you're piping through a…
+1 (upvoted).
$ less ./somefile
/somesearch^M (Re: Stop using tail -f (mostly)
#17Even when you don't want less +F, a good alternative to tail -f is tail -F. It survives log rotation, and the file being temporarily inaccessible: --retry keep trying to open a file even if it is inaccessible when tail starts or if it becomes inaccessible later; useful when follow- ing by name, i.e., with --follow=name -F same as --follow=name --retry
+1 for -F. Note that --follow and --retry are gnuisms, while -F works on most implementations of tail (even though it's not part of POSIX).
Re: Stop using tail -f (mostly)
#18Be very, very careful with this: http://seclists.org/fulldisclosure/2014/Nov/74
But really, it's 2015. Are you really using a terminal emulator without a buffer search? Are you not using screen or tmux, both of which can do these things natively, with no external tools? Why? And what is wrong with backgrounding the tail command, running your grep, and then foregrounding the tail command?
Re: Stop using tail -f (mostly)
#19Even when you don't want less +F, a good alternative to tail -f is tail -F. It survives log rotation, and the file being temporarily inaccessible: --retry keep trying to open a file even if it is inaccessible when tail starts or if it becomes inaccessible later; useful when follow- ing by name, i.e., with --follow=name -F same as --follow=name --retry
Yeah, tail -F is the way to go imo.
Also, if you are using a proper ssh client, opening a second ssh connection to manage the reacting to the log files is habit for me at this point. The only time I'm using tail -F is after a new configuration deployment. Otherwise, I'm looking at archival data in ELK.
Re: Stop using tail -f (mostly)
#20It's a nice feature of less, but less is a pager, so you can't pipe the result to `grep` or `sed` or `awk` or something.