
Stop using tail -f (mostly) - Pdincau
http://www.brianstorti.com/stop-using-tail/?utm_content=buffer13c97&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer
======
pimlottc
I 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.

~~~
evincarofautumn
With less, you can use m<letter> to mark the current position and '<letter> to
go to a marked position. h will show you lots of useful help.

~~~
bch
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)
      * ...

~~~
pjungwir
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, although I
could also say `vi -R` to prevent it.

\- Starving the production system of memory. I'm pretty sure he expressed this
concern. Any insight into whether it is legit? Is less actually any better?

Obviously you really should have a log shipping & aggregation service so you
can read logs offline, etc, but not every project is large enough for that,
nor every org organized enough. So for the sake of argument my premise is,
"Assuming you want to read a log on production . . ."

~~~
vbezhenar
On large files less fires up immediately and vim is quite slow. I think that
vim is loading an entire file in the memory while less just loads visible
chunk. May be other vi implementations are more efficient with large files.

Besides — vim really shouldn't be used on log files. It's editor, not viewer.

~~~
pjungwir
> Besides — vim really shouldn't be used on log files. It's editor, not
> viewer.

I think the two concerns I stated are probably legit, but this one is boring
to me. Vim is nicer than less for reading files. I have more navigation
commands. I can yank part of the file and save it somewhere else. I can pipe a
range of lines through awk/etc. I can switch between files. I can split my
screen. Etc. Some of these are probably available in less too (more than
more(1) supported in 2001), but I doubt all, and I already know the commands
in vim. I'm interested in not clobbering my logs and not crashing the server,
but if you tell me vim is an editor not a viewer, I'll ask Why?

Btw re-reading my words I don't mean to sound combative. But the point of my
original question was to _understand_. I've been cargo-culting "use less for
logs" for 14 years already.

~~~
kragen
You can save a part of the file, pipe a range of lines, or switch between
files in less, too, and the commands are mostly the same as in vi. It'd sure
be nice to be able to split the screen, though!

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

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

~~~
noddingham
Have you tried using screen[1]? Might make things a little easier than have
two separate SSH connections.

[1]
[https://www.gnu.org/software/screen/](https://www.gnu.org/software/screen/)

~~~
fweespeech
Yes. I use it when I need to resume a SSH session. Given proper configuration,
switching SSH tabs/connections is as easy as switching browser tabs...there is
no real need for me to use screen for such a purpose.

Thank you for the suggestion tho. :)

------
scrame
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 script for processing, tail -f is
still the best bet. If you need multiple files, multitail is probably better.
less +F hits a quick+easy operational niche and is available almost everywhere
(whereas multitail is not).

~~~
twic
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

~~~
barrkel
& is very handy, however it is also excruciatingly slow. It looks like it uses
an O(n^2) algorithm, just from observing how slow it works.

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

------
sciurus
If you're looking at log files, a tool I've started to play with is
[http://lnav.org/](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.

~~~
beernutz
That looks very nice! Thanks for the info. 8)

------
jetpks
If you're using a modern terminal with scrollback, you already have the
ability to pause, and scroll back.

    
    
        # tail -f busy.log
        < see something of interest >
        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.

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

~~~
jetpks
Correct, however the author is saying that there's no reason to ever use tail
unless you're tailing multiple files, which is false. _Most_ of the
functionality you want is already built into your terminal emulator. If you
want slower updates (`less` uses 1 second polling, vs `tail` [inotify]), and
the ability to search, by all means, use `less`.

~~~
kragen
Hmm, someone should add inotify handling to `less`.

------
tikums
Or use multitail. It supports syntax highlighting, among other features:
[http://www.vanheusden.com/multitail/](http://www.vanheusden.com/multitail/)

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

~~~
0x0
Also take a look at ccze which is great for syntax-coloring all kinds of log
files heuristically.

For example: tail -F somefile.log|ccze -A

For your shell, there's a lot of funky colorful interactive customizations you
can get on zsh and fishfish.

~~~
acdha
That's really nice – thanks for the pointer. "ssh … varnishncsa | ccze" worked
first time without any config, exactly as you'd want.

------
stonogo
Be very, very careful with this:
[http://seclists.org/fulldisclosure/2014/Nov/74](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?

~~~
Filligree
Personally? The reason I'm not using screen is that there's no way to
atomically [attach, create new window] in screen and I value my gnome-terminal
tabs.

If tmux can do that, then I'd consider it reason to switch.

~~~
vacri
Check out 'byobu'. Stupid name, but it's built on screen and can use the
screen commands. Byobu has F2 for new terminal tab, F3/4 to shuffle between
them.

------
spatz
The problem is that less +F polls every second while tail -f uses inotify,
which is both more efficient and responds faster to change.

~~~
haberman
I always thought it was such a shame that you couldn't use plain poll() for
this. poll()-ing on a read fd at EOF for a regular file should work like
poll()-ing a network socket.

~~~
ekimekim
The problem is in what concepts are being considered "the same" when mapping
two mostly-dissimilar things (a socket or pipe, vs a file).

poll(), select() et al don't define "readable" as meaning "a byte of data is
available". They define it as "read() will not block".

When you read to the end of a file, read() returns "". This is the same as
when you try to read from a closed socket. Conceptually, they are linking the
concepts of "EOF" and "closed", not the concepts of "EOF" and "waiting for
data". And indeed, if you call poll() on a socket that has been closed on the
remote end, you will find it is "readable".

Ultimately, regular files just were never intended to be used as pipes. The
abstractions just weren't chosen to work in that way.

~~~
haberman
> poll(), select() et al don't define "readable" as meaning "a byte of data is
> available". They define it as "read() will not block".

If that were true, poll() wouldn't return read-ready on a file-based fd until
the data was actually sitting in buffers. After all, that's the only way to
guarantee it won't block. That would actually be a useful semantic.

But what actually happens is that poll() on a file-based fd is basically a no-
op that always returns true immediately, AFAIK. Someone could pull the disk
drive cable before you actually call read(), in which case read() _will_
indeed block, forever.

The existing semantic is useless. What argument is there in favor of a useless
semantic?

This semantic wouldn't solve the "tail -f" problem, but at least it would be
useful:
[http://cr.yp.to/unix/asyncdisk.html](http://cr.yp.to/unix/asyncdisk.html)

------
reidrac
Not convinced, still like tail -f because you can hit enter a couple of times
and there you are... a nice visual mark to wait for new data without getting
confused by existing content.

All this in my humble opinion. less is useful and I may use F to wait for data
if I was looking for something in old logs, but for new data I still like tail
-f :)

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

~~~
nilkn
I'd wager that 90% of the time that I'm using 'tail -F' I'm also piping it to
grep.

~~~
jfroma
This. I use:

tail -f /var/log/x.log | grep foo -A 20 -B 20

Most of the time.

~~~
gitaarik
You know you can also do -C 40 for 40 lines of context instead of -A 20 -B 20

~~~
nkouevda
Note that -C is in each direction, not total; -C20 is equivalent to -A20 -B20.

~~~
jfroma
Thank you,

This is the reason I always share how I do it in hn! LOL

------
kolme
I use tail -f inside tmux anyways, so I already have the extra feature less
offers ("navigation mode", searching, etc) without giving up the "watch
multiple files" feature.

A much nicer alternative, IMHO.

------
orthecreedence
I use tail -f with tmux usually. Will less +F save the entire output into
memory? In other words, if I accidentally leave it open in a tmux shell and
the log grows to 300mb of output, will the server start swapping?

~~~
kragen
I usually run `less` niced and with a ulimit of 30 megabytes, but `less` also
has an option to configure how much buffer space to use. As far as I can tell,
the default is "all of your memory", which is a suboptimal default in my book.

------
tstack
There's also lnav ([http://lnav.org](http://lnav.org)), the Logfile Navigator.
It can do what 'tail -f' and 'less' do plus: syntax coloring, filtering,
loading compressed files, interleaves log messages from multiple files, and
more.

Many of the comments I see on here about using '-F' with tail instead of '-f',
live searching, and so on are handled in lnav by default. I would really
encourage folks to give it a try.

------
mrinterweb
One advantage that tail -f has is that you can insert newlines or other
characters into the output to help you visually split log entries. Log files
often look the same so being able to visually split up the log is very helpful
IMO.

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

------
nailer
On current Linux distros, you're more likely to use:

    
    
        journalctl -u service-name -f
    

-f, --follow Show only the most recent journal entries, and continuously print new entries as they are appended to the journal.

~~~
barnacs
I prefer the more expressive

    
    
      journalctl -fu service-name

------
r0naa
Interesting.

I always preferred

    
    
      watch -n 1 -d 'tail /path/to/log/file'
    

to tail -f

because of its nice highlighting feature.

~~~
pimlottc
watch is one of the great unsung heroes of unix tools. Discovering it was one
of those "I wish I knew about this years ago" moments. Unfortunately it
doesn't seem to have spread much beyond GNU/Linux platforms.

------
w4tson
+1 for Commandline Fu. I love it when you see a colleague at a terminal and
you say "Whoah, go back, what was that you just did?". It's kinda beautiful
really, the way everyone has slightly different methods for common dev tasks
at the commandline.

My method is usually '+G' to go to the end of the log file and check the
damage report. Quick reverse search with '?' \+ search term to find last
error, then probably hit 'n' to find the next previous any other occurrences
to determine how frequent it's popping up. If it looks like it's a recurring
problem i'll '+F' to see follow latest output. Then CTRL+c to quit that mode.

tail -f still has it's uses for cases as pimlottc mentioned. I like to put a
bit of distance between the last bit of output. Especially if its a
particularly repetitive and lengthy stacktrace.

~~~
relaxitup
I use tac file |less often to start at the end of the file..

------
tristor
I use tail -f mainly for tracking something end-to-end through multiple log
files because it's pipeable to grep or awk, where less is not. less +F is cool
too, but tail -f is more useful when doing complex log analysis on the fly
because it follows standard UNIX I/O behavior.

------
jaryd
I just tried this on an extremely active logfile and it didn't work very well
for me. I'd recommend multitail for watching constantly changing files.

------
pearjuice
Stop using [commonly accepted, proven method] and use [obscure alternative]

Textbook HN hit.

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

~~~
varikin
That only works if you only care about search results since you started
tailing. If you want to search for what happened before you started tailing,
you need to stop tailing and use less/grep/etc.

~~~
jabo
Ah yes. I usually let the tail -f run, open another SSH session and grep from
there.

------
UserRights
What do people (you) think about browser based log viewers like e.g.
logio.org? I like to comfortably have all the logs in the browser but do not
want to go full ELK (or anything in this category) stack just for a few
servers. But I am not sure if there is some better solution? Multitail is
great, but sometimes just opening a new browsertab is even greater...

------
emilsedgh
For lazy people out there:

There is also the command `tailf` which is quite similar to 'tail -f'.

2 characters make so much difference :)

~~~
colechristensen
alias tf='tail -f'

I saved you three more!

~~~
le_lenny_face
GRUB_CMDLINE_LINUX_DEFAULT="init=/usr/bin/tail"

Maximum savings!

------
agopaul
For semi-large file (1/2GB+) less takes seconds if not minutes to count the
number of lines (it read the whole file) so you can navigate and search across
the file. In that cases tail -f and grep are still way faster than less,
though less is a handier tool

~~~
toddkaufmann
You don't have to wait. You can turn that off with '-n'.

When you jump to the end of the file ('>' command) you'll see "Calculating
line numbers... (interrupt to abort)" and interrupt (ctrl-C) here will also
turn them off.

~~~
agopaul
I didn't know about the -n switch. Usually I need to get to the bottom of the
file and find the last occurrence of a string in the logs (G, CTRL+C to stop
counting lines, ?string to search) and the slower part is waiting for less to
match a string going backwards on the file. Will check if the -n switch solves
the problem

------
thebouv
Searching with less is a cool feature, but I think the best thing I learned
was to use -F instead of -f with tail thanks to the comments on the article
and HN.

Of course I'll probably fail to use any of it because of finger memory just
typing out tail -f for me.

------
ewindisch
I would be careful about such casual use of less:
[http://seclists.org/fulldisclosure/2014/Nov/74](http://seclists.org/fulldisclosure/2014/Nov/74)

------
pcwalton
less is my favorite text editor. It's a pity it doesn't actually edit text.

~~~
soyuka
You should try vim dude.

------
Animats
It's amusing to read this just as, for the first time in months, I have a
"tail -f" running. I just converted a medium-sized system from Python 2 to
Python 3 (this is not fun; I had to fix or work around five bugs in external
modules), and deployed it this morning. So I have a "tail -f" running in
"putty", watching an Apache server error log. (I know, retro.) This is just in
case there's some new Python-level error; operational errors are logged to the
database. The log is quiet, and soon I can stop watching.

------
prydonius
I was interested in the significance of the plus for this flag. If anyone else
was curious: from the manual, the + flag is for initial commands to less, so
this is equivalent to running less and typing F.

------
fidz
Thanks! This is really great trick. I will obviously use less +F _for tailing
single file_.

Meanwhile, tail -f still useful for simple tailing to multiple machine, like

    
    
        function dogfight_tail {
         logfile=/var/log/nginx/access.log
         pids=""
         for box in 02 03; do
           ssh lb$box tail -f $logfile | grep " 500 " & # find error machines
           pids="$pids $!"
         done
         trap 'kill -9 $pids' SIGINT
         trap  wait
        }
    
        dogfight_tail

------
64bitbrain
I use "tail -f" most of the time. Sometimes, I just dig more and use grep with
it.

tail -f sys.log | grep NETDEV

But I would definitely give this a try, thanks for sharing.

------
monokrome
I think that it's worth noting that you should still use `-f` if you are
viewing a file over SSH that is being appended to a ton and you don't need
every line. SSH will require that every line makes it to your terminal over
it's secure connection, so you will be bottlenecked and most likely won't be
viewing the latest messages. Everything will be queued.

------
ahomescu1
I think I'll do the following (as a joke, surprised no one did it already):

    
    
      $ alias stalk='less +F'

------
fsniper
I just had an SRE screening and one of the questions was

"What is a linux command that's mostly not known?".

I could not remember anything that's special, at least for me at the time but
"less -F" poped up to my mind. Thank you :)

Oh now I can think of ccze, column and tac. Interviews..

------
soyuka
With `tmux` there is a visual mode that allows to `tail -F` with search,
selection etc.

------
jordanpg
For something simple and very lightweight for Windows development, check out
BareTail:
[http://www.baremetalsoft.com/baretail/](http://www.baremetalsoft.com/baretail/)

------
awalGarg
Haha I didn't know a lot of people didn't know about this. I am one of those
people who likes to read man pages :D Another favorite one of mine is the `v`
switch to quickly jump to the editor from `less`. Pretty handy!

------
crypt1d
While I understand that the author is just trying to be helpful, the
provocative title of the article makes me want to scream: "Stop telling me
which tool is right for MY job."

------
jimmaswell
I've literally never had this problem and nothing is wrong with tail -f for
me. Quitting tail to use grep on the file is anything but inconvenient for me.

------
jcfrei
The biggest nag I have with tail is that it stops tracking a file once it gets
moved and a new one is created in its place (through log rotation).

~~~
vially
As mentioned by others in this thread, you can use: "tail -F data.log"

------
bmoresbest55
This is pretty awesome. I have always thought that "tail -f" was a little
limited but still useful. Any how, great post!

------
sbov
For log files that move particularly fast, I prefer to use "watch tail -n 100"
so I don't choke my connection.

------
BrandonBradley
Good share! Command line fu is always nice.

------
realrocker
$make -j16 showcommands > build.log 2>&1 | less +F

ctrl+c...

<shit its not working>

ctrl+c * 1e9 impatiently

...

build stopped

oops

------
decentrality
It would be awesome to remove the "Waiting for data... (interrupt to abort)"
message.

~~~
decentrality
Passing -Pw without a prompt at least gets that down to "... (interrupt to
abort)"

------
karlgoldstein
Or just tail -f in an emacs buffer

~~~
VLM
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 to revert, default is about a
sip of water (a few seconds?) but I guess you could crank it down to 1 second
or something.

I like doing this in emacs so its all in the same ecosystem, if I need to cut
and paste something weird to test it or put the message into code or even more
likely to cut and paste actual error messages into docs or comments, I can do
it inside emacs.

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

------
BorisMelnik
"here you have pretty much the same behavior"

what is meant by 'pretty much?'

------
shirro
Perhaps neovim with terminal mode and tail -F might be the best of all worlds.

------
decentrality
Doesn't read ANSI color codes! Looking through manual for that.

~~~
decentrality
SOLVED: less +F -R <file>

Interprets color codes as RAW, relaying them to the screen as-is.

------
oimaz
less +F is not such a good alternative to "tail -f" or better "tail -F"
especially when you are filtering the output of tail using grep or awk.

~~~
rcthompson
I imagine you could probably do "tail -f | grep/awk ... | less +F".

~~~
simgidacav
It works fine indeed. I'm using it all the time.

------
xxdesmus
Imma just gonna leave this here:
[http://seclists.org/fulldisclosure/2014/Nov/74](http://seclists.org/fulldisclosure/2014/Nov/74)

------
amelius
Why not just pipe the output of tail -f through less?

------
ircuse
Put that kind of suggestion in coderwall.com

------
sigzero
Solaris 10 doesn't have the -F flag.

------
luckymedonwon
Can I hack someone's pay face book

------
zobzu
U dont tell me what to do! i like my tail

/thefox

------
luckymedonwon
Can you hack face book account

------
aweiher
its not better for me, hitting enter is essential for me when using tail

------
mdekkers
...or use multi-tail

------
snambi
wow... this is really a nice coomand

------
ephexeve
Nice!

------
igorgue
Wait... Isn't less gonna read the whole file at first? That might suck for
files that are already huge.

~~~
quicklyfrozen
No. I use less to navigate gigabyte log files quite often (it's more efficient
then vim).

------
sixothree
Linux just really needs PowerShell.

~~~
zer0rest
hahahaha, No.

~~~
sixothree
Enjoy your parsing text files. I'll work with objects instead.

~~~
simgidacav
Eventually Microsoft will be able to reinvent Unix. Just keep the faith.

------
_RPM
tail works best for me. I'm not going stop using it just because a person on
the internet says not to.

~~~
TorKlingberg
The title is a bit clickbaity, but ignore that and it's a useful tip you might
not know. The author doesn't actually demand you stop using tail -f if you
like it better.

