Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stop using tail -f (mostly)

brianstorti.com

Post reply on HN
Print view View original

51–60 of 211 posts

Re: Stop using tail -f (mostly)

#54

Post by jetpks »

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.

Re: Stop using tail -f (mostly)

#55

Post by smorrow »

drzaiusapelord wrote: post #13
tikums wrote: post #6

Or 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…

I use htop and turn the colours off... thing I like about htop is I can use the mouse. It's so F-key-based, which, especially on a laptop, means you have to take your eyes off the screen to find the keys.

Of course, I'm not opposed to colours, I'm opposed to colours that look tacky / l33t hax0r, which would be most terminal stuff. I like 𝐛𝐨𝐥𝐝 better than trying to find colours I won't hate.

Re: Stop using tail -f (mostly)

#56

Post by twic »

scrame wrote: post #8

This _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…

The other useful thing is filtering - on sufficiently modern versions of less [1], you can use & to filter the lines, in the same way you use / to search them - only lines matching the filter are shown, and the display continues to update. Use &! for a negative filter. This has replaced grep | tail for me, with the advantage that it's non-destructive, so you can undo the filter, reapply a different one, etc.

[1] Everything i've used on Linux in the last few years, not the vanilla one on the Mac, but the one in Homebrew

Re: Stop using tail -f (mostly)

#57

Post by sciurus »

If you're looking at log files, a tool I've started to play with is http://lnav.org/

= In Your Terminal = Many logging tools, like Splunk, provide great features but are optimized for large-scale deployments. They require installing and configuring servers before they can be effectively used. There is still a need for a robust log file analyzer for the terminal.

= Easy to Use = Just point lnav to a directory and it will take care of the rest. File formats are automatically detected and compressed files are unpacked on the fly.

= Improved Presentation = Log files are a wealth of information, lnav can help highlight the parts that are important and filter out the noise.

Re: Stop using tail -f (mostly)

#58

Post by prakashk »

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.

This is not a replacement for searching for a specific string in `less` which highlights the matches, and eliminates the need for scanning the text manually which is harder and prone to missing information.

Re: Stop using tail -f (mostly)

#59

Post by shabble »

VLM wrote: post #42
karlgoldstein wrote: post #29

Or just tail -f in an emacs buffer

You mean like in multiterm or something? I guess so. In emacs there are always many ways to do things, which is awesome. You can also open the file and engage auto-revert-mode or auto-revert-mode-tail. In my status bar it shows up as ARev mode. Also you can bind those to your auto-mode-alist so all .log files get the tail treatment or whatever. Scrolling can get weird. Theres some google-able settings for the timeout…

It looks like from ~24.4 onwards there's support for various notification event sources for auto-revert[-tail]-mode, as determined by the file-notify--library variable. I don't appear to have anything compiled into my prebuilt OSX emacs though, time to update the ol' source tree and see if I can remember how to build it.
Post reply on HN