[laumars]

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

[TallGuyShort]

Not if you also need to search things that weren't at the end of the file when you started tailing - which is very common with log files.

[laumars]

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 thing about this method is you can still pipe grep (which you couldn't do with less) so if you are writing out ~2000 lines rapidly enough that the content you want wouldn't be at the bottom, you can manage the text stream more efficiently (ie grep -v out stuff you don't want or only grep in the content you do want)

I should add that I am a fan of less on many occasions, but in this instance the piping ability of tail is a deal breaker when working with larger files.

[edwintorok]

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

[TallGuyShort]

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.

[laumars]

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?

[TallGuyShort]

Fair enough. My apologies for how that was conveyed.

[kakakiki]

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.

[laumars]

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

[XorNot]

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.