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

191–200 of 211 posts

Re: Stop using tail -f (mostly)

#191

Post by tom-lord »

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…

You can also achieve this by doing:

tail -f whatever.log | grep --color=auto -C99 exception

And there are other ways pausing/scrolling back, such as tmux's scroll mode.

Re: Stop using tail -f (mostly)

#192

Post by pjungwir »

annnnd wrote: post #185
pjungwir wrote: post #72

Earlier quoted context omitted.

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…

From sysop standpoint there is a huge difference: 1) for user: less chance (pun intended) to actually change the file when all you wanted was to read it 2) for sysadmin: if sysadmin sees "less somefile.log" in bash history, he knows the user just read the log. If he sees "vi somefile.log" then he doesn't know if the user has also changed the log file (maybe not even knowing it). The assumption is that you deal with n…

Thanks for your reply! Since I do a lot of devops I've tried over the years to formulate a mental model of how a sysadmin thinks and what they care about. I'd never have thought about this auditability concern, so it's something to add to my list! :-)

Re: Stop using tail -f (mostly)

#193

Post by acdha »

rjcz wrote: post #183
acdha wrote: post #86

Earlier quoted context omitted.

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

Why would they? It's not needed - '-F', '--retry' and the like are redundant. IMVHO, OpenBSD's '-f' behaviour should have been the default elsewhere, too. How many times in the past have you deliberately followed the file descriptor (coreutils' default '-f' behaviour) instead of its name? Every single time I used it in the past on Linux, this is what I thought: "For f***** sake! I should have used '-F'! Arghhh...!" O…

I'm not saying that the OpenBSD behaviour is wrong but that compatibility is a worthwhile goal. Adding a simple -F alias for their existing behaviour would allow people's habits & shell scripts to just work without changes.

Re: Stop using tail -f (mostly)

#194

Post by acdha »

protomyth wrote: post #158
acdha wrote: post #153

Earlier quoted context omitted.

If you want to be pedantic, no, it's not a bug but in the vast majority of the software world people use the term “bug tracker” to refer to a system which also tracks new work which isn't strictly a defect. And, since we're being pedantic, when I said “vast majority of the software world”, that includes the OpenBSD project: “Sending in bug reports If possible, use the sendbug(1) command to get the bug into our tracki…

Ok, but it has an -f behavior that seems to do the right thing. I don't think I would file a request to add flags that aren't needed. I'm not being "pedantic", I just don't think there is anything to change.

The idea is that if everyone else is converging on "tail -F" supporting that as an alias means that people's habits & shell scripts just work without modification. That seems worth adding a single line to a switch statement to me.

Re: Stop using tail -f (mostly)

#195

Post by XorNot »

laumars wrote: post #190
kakakiki wrote: post #180

Earlier quoted context omitted.

I see that tmux doesn't come as part of standard ubuntu installation. So I think that puts it at a disadvantage for not being omnipresent.

Neither is about 99% of the other software that Ubuntu desktops and servers run daily. Hence why we have software repositories and user friendly package managers to make installing new software a breeze: apt-get install tmux

byobu is a sink-included tmux distribution in Ubuntu, that does most of the hard setup work for you.

I still like tmux for getting several servers in debug mode on the same screen when using docker though.

Re: Stop using tail -f (mostly)

#196

Post by TallGuyShort »

edwintorok wrote: post #188
laumars wrote: post #116

Earlier quoted context omitted.

Generally you wouldn't want auto updating like the less +F or tail -f if the content you wanted was at the start of the file. However you can still work around those rare instances by specifying the -n flag. eg tail -n 2000 -f The beauty of this is a file with less that 2000 files will be read in it's entirety, and you're gracefully managing larger files by cropping out the surplus data at the beginning. And the best…

Also searching with grep is a lot faster than searching with '/' in less when the file is really large.

Yes and grep isn't very good for interactive searching. There's lot of different ways you could do this, and they all have pros and cons depending on the situation. My point was that all these posts dismissing this blog post as pointless are just arrogant. Most people don't know about less +F, but it's pretty handy for some common use cases. So he didn't mention someone's favourite tool - it's okay.

Re: Stop using tail -f (mostly)

#197

Post by notfoss »

annnnd wrote: post #185
pjungwir wrote: post #72

Earlier quoted context omitted.

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…

From sysop standpoint there is a huge difference: 1) for user: less chance (pun intended) to actually change the file when all you wanted was to read it 2) for sysadmin: if sysadmin sees "less somefile.log" in bash history, he knows the user just read the log. If he sees "vi somefile.log" then he doesn't know if the user has also changed the log file (maybe not even knowing it). The assumption is that you deal with n…

  for sysadmin: if sysadmin sees "less somefile.log" in bash history, he knows the user just read the log. If he sees "vi somefile.log" then he doesn't know if the user has also changed the log file (maybe not even knowing it).
In case you didn't know, you can invoke an editor from within less by pressing 'v'. And that wouldn't get registered in the shell history ;)

Re: Stop using tail -f (mostly)

#198

Post by laumars »

TallGuyShort wrote: post #196
edwintorok wrote: post #188

Earlier quoted context omitted.

Also searching with grep is a lot faster than searching with '/' in less when the file is really large.

Yes and grep isn't very good for interactive searching. There's lot of different ways you could do this, and they all have pros and cons depending on the situation. My point was that all these posts dismissing this blog post as pointless are just arrogant. Most people don't know about less +F, but it's pretty handy for some common use cases. So he didn't mention someone's favourite tool - it's okay.

At no point did I dismiss his post nor show any arrogance towards the author:

> Not that I'm trying to dismiss the effectiveness for +F for those inclined

> kudos to the author for his recommendation and providing helpful write ups to future sysadmins

The ironic thing is, you've been far more dismissive about other peoples suggestions than I had of the author's. As you said yourself, there are a lot different ways this can be done, so why limit us to discussing only one possible solution?

Re: Stop using tail -f (mostly)

#199

Post by pjungwir »

notfoss wrote: post #197
annnnd wrote: post #185

Earlier quoted context omitted.

From sysop standpoint there is a huge difference: 1) for user: less chance (pun intended) to actually change the file when all you wanted was to read it 2) for sysadmin: if sysadmin sees "less somefile.log" in bash history, he knows the user just read the log. If he sees "vi somefile.log" then he doesn't know if the user has also changed the log file (maybe not even knowing it). The assumption is that you deal with n…

for sysadmin: if sysadmin sees "less somefile.log" in bash history, he knows the user just read the log. If he sees "vi somefile.log" then he doesn't know if the user has also changed the log file (maybe not even knowing it). In case you didn't know, you can invoke an editor from within less by pressing 'v'. And that wouldn't get registered in the shell history ;)

Ha ha, this reminds me of the days I had sudo access to `vi` but not a lot of other commands, on a box that IT didn't really want to support. . . .

Re: Stop using tail -f (mostly)

#200

Post by sukilot »

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…

The sysadmin was low knowledge.

You should download the log file and view it locally. You should never run ad hoc commands on a live production sytem.

And there is no reason that you should have edit privileges on the log file anyway.

Post reply on HN