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

81–90 of 211 posts

Re: Stop using tail -f (mostly)

#81

Post by freehunter »

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…

Switching between many programs and systems, I have a hard time keeping track of what colors mean what. Especially when people start customizing their colors. There are enough tools to show you what a file is, I don't need directories printed in red and files in blue and symlinks in green. ls -l is good enough and works everywhere.

Re: Stop using tail -f (mostly)

#82

Post by mattikus »

gitaarik wrote: post #20

It'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.

While you may not be able to do transforms on the output via `sed` or `awk`, you can get a grep-like filtering by using the `&` character with `less` open.

Re: Stop using tail -f (mostly)

#83

Post by bch »

pjungwir wrote: post #70
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) * ...

Just the other day I was looking for a way to do this in less: yank 10 lines, open a new file, paste the 10 lines, save the file. Is that possible? My Googling last week didn't find a good solution.

If you wanted to grab 10 lines from /var/log/messages, starting at the first line that has "pjungwlr" in it, you could:

  $ less /var/log/msgs
  /pjungwlr^M
  ^G (note line informational line numbers)
  v (launch vi)
  [double check your line #s, etc]
  :d1,. (delete from 1st line, to current line)
  10j (go down 10 lines)
  :d,$ (delete to EOF)
  :w my_newfile
  :q

Re: Stop using tail -f (mostly)

#84

Post by bkeroack »

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 would never "yell" at anybody for using vi vs less, but I might curiously ask their reasoning behind it. I'm generally for less bikeshedding and cargo cultism when possible. Whatever works to get the job done.

Re: Stop using tail -f (mostly)

#86

Post by acdha »

protomyth wrote: post #39
nothrabannosir wrote: post #9

Even 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

on OpenBSD -f does: Do not stop when end-of-file is reached, but rather to wait for additional data to be appended to the input. If the file is re- placed (i.e., the inode number changes), tail will reopen the file and continue. If the file is truncated, tail will reset its position to the beginning. This makes tail more useful for watching log files that may get rotated. The -f option is ig- nored if the standard in…

Is there a bug report open for that yet? FreeBSD has this so they should be able to resync easily enough

Re: Stop using tail -f (mostly)

#87

Post by Florin_Andrei »

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.

There was a time when tail didn't know inotify. It was so, so much better when it learned that trick.

There was also a time when there was a utility called inotail, bridging that gap until tail proper was improved. I very much preferred it over regular tail.

Re: Stop using tail -f (mostly)

#89

Post by lgas »

toddkaufmann wrote: post #67
jimktrains2 wrote: post #28

Earlier quoted context omitted.

GP isn't meaning it like that, they mean being able to add some spaces so that the next log entries stand out for quick visual identification as you're making changes and reloading the application.

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.
Post reply on HN