13 ms·

Stop using tail -f (mostly)

765 points by Pdincau 12y ago

BrandonBradley 12y ago
Good share! Command line fu is always nice.
jaryd 12y ago
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.
_RPM 12y ago
tail works best for me. I'm not going stop using it just because a person on the internet says not to.
- TorKlingberg 12y ago
  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.
jabo 12y ago
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 12y ago
  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 12y ago
    Ah yes. I usually let the tail -f run, open another SSH session and grep from there.
- mason55 12y ago
  This only works if what you are searching for has scrolled past since you started following. If you want to see other occurrences in the file you're out of luck. For example, let's say you are watching to see which error message is generated when something goes wrong, then you want to see when else that error message has been thrown.
tikums 12y ago
Or use multitail. It supports syntax highlighting, among other features: http://www.vanheusden.com/multitail/ http://www.vanheusden.com/multitail/
- drzaiusapelord 12y ago
  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 12y ago
    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 12y ago
      That's really nice – thanks for the pointer. "ssh … varnishncsa | ccze" worked first time without any config, exactly as you'd want.
  - smorrow 12y ago
    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.
scrame 12y ago
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).
- bch 12y ago
  +1 (upvoted). $ less ./somefile /somesearch^M (<--- does a search) F (<--- puts less(1) in "follow mode", highlighting your previous search-term if it occurs in the future) (Edit: formatting)
  - wampus 12y ago
    But how do you combine the two on the command line, so less is tailing the file AND highlighting a pattern when launched? I typically read logfiles with less +F, but it would be nice to create an alias for patterns in specific types of logs, so I don't have to remember them or rely on command history.
    - bch 12y ago
      $ less +F +/mypattern^M /my/file/to/search_and_follow * Note that I needed to "quote" (^V^M) that carriage-return to get the search pattern to work. Happy searching-and-following.
      - wampus 12y ago
        Thanks! Any idea what the quoted carriage return does? I wouldn't have thought of that in a million years.
        12y ago
nothrabannosir 12y ago
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
- varikin 12y ago
  This is my standard now. Logs rotate all the time and it very convenient to have tail continue working without my intervention.
- pimlottc 12y ago
  +1 for -F. Note that --follow and --retry are gnuisms, while -F works on most implementations of tail (even though it's not part of POSIX).
- fweespeech 12y ago
  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 12y ago
    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/
    - baq 12y ago
      c.f. tmux
    - fweespeech 12y ago
      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. :)
nmc 12y ago
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.
pimlottc 12y ago
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 12y ago
  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.
  - jimktrains2 12y ago
    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.
    - toddkaufmann 12y ago
      Use '/' (search) to enter a regexp to match a pattern on that line, and it will be highlighted.
      - lgas 12y ago
        This has nothing to do with what is being discussed in this subthread.
        teraflop 12y ago
        Sure it does. If your log lines are distinct (e.g. they have timestamps or unique IDs) then you can use less's search highlighting to provide a visual marker for a specific line, similar to what you can do by manually inserting a bunch of blank lines on the console. This trick doesn't work if your log file has a bunch of identical lines and you want to keep an eye on their rate, though.
stonogo 12y ago
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 12y ago
  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.
  - yellowapple 12y ago
    Do you mean creating a new window every time you attach to an existing session? Or do you mean that each of those actions ("attach" and "create new window") should be atomic?
  - vacri 12y ago
    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.
  - philsnow 12y ago
    Depending on what you mean by "atomic" (do you really mean atomic, or do you just not want to have to type anything after you've attached to create the new window?), you can do this with screen's -X option. If that's what you want to do I can try to dig up the way I used to do this.
gitaarik 12y ago
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.
- mattikus 12y ago
  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.
- nilkn 12y ago
  I'd wager that 90% of the time that I'm using 'tail -F' I'm also piping it to grep.
  - jfroma 12y ago
    This. I use: tail -f /var/log/x.log | grep foo -A 20 -B 20 Most of the time.
    - gitaarik 12y ago
      You know you can also do -C 40 for 40 lines of context instead of -A 20 -B 20
      - nkouevda 12y ago
        Note that -C is in each direction, not total; -C20 is equivalent to -A20 -B20.
        jfroma 12y ago
        Thank you, This is the reason I always share how I do it in hn! LOL
pcwalton 12y ago
less is my favorite text editor. It's a pity it doesn't actually edit text.
- soyuka 12y ago
  You should try vim dude.
orthecreedence 12y ago
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 12y ago
  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.
- simgidacav 12y ago
  That's an important point: never use this trick with huge logs...
mrinterweb 12y ago
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.
spatz 12y ago
The problem is that less +F polls every second while tail -f uses inotify, which is both more efficient and responds faster to change.
- Florin_Andrei 12y ago
  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.
- haberman 12y ago
  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 12y ago
    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 12y ago
      > 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
karlgoldstein 12y ago
Or just tail -f in an emacs buffer
- VLM 12y ago
  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 12y ago
    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.
oimaz 12y ago
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 12y ago
  I imagine you could probably do "tail -f | grep/awk ... | less +F".
  - simgidacav 12y ago
    It works fine indeed. I'm using it all the time.
jcfrei 12y ago
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 12y ago
  As mentioned by others in this thread, you can use: "tail -F data.log"
emilsedgh 12y ago
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 12y ago
  alias tf='tail -f' I saved you three more!
  - le_lenny_face 12y ago
    GRUB_CMDLINE_LINUX_DEFAULT="init=/usr/bin/tail" Maximum savings!
igorgue 12y ago
Wait... Isn't less gonna read the whole file at first? That might suck for files that are already huge.
- quicklyfrozen 12y ago
  No. I use less to navigate gigabyte log files quite often (it's more efficient then vim).
64bitbrain 12y ago
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.
deleted 12y ago
[deleted]
zobzu 12y ago
U dont tell me what to do! i like my tail /thefox
nailer 12y ago
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 12y ago
  I prefer the more expressive journalctl -fu service-name
tstack 12y ago
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.
kolme 12y ago
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.
thebouv 12y ago
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.
realrocker 12y ago
$make -j16 showcommands > build.log 2>&1 | less +F ctrl+c... <shit its not working> ctrl+c * 1e9 impatiently ... build stopped oops
ephexeve 12y ago
Nice!
sixothree 12y ago
Linux just really needs PowerShell.
- zer0rest 12y ago
  hahahaha, No.
  - sixothree 12y ago
    Enjoy your parsing text files. I'll work with objects instead.
    - simgidacav 12y ago
      Eventually Microsoft will be able to reinvent Unix. Just keep the faith.
- deleted 12y ago
  [deleted]
jetpks 12y ago
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 12y ago
  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.
  - falcolas 12y ago
    Most terminals also offer searching capability, which do not result in disk seeks on the remote host.
  - jetpks 12y ago
    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 12y ago
      Hmm, someone should add inotify handling to `less`.
- Yizahi 12y ago
  But it won't show me old parts of the log and I usually want this.
sciurus 12y ago
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 12y ago
  That looks very nice! Thanks for the info. 8)
crypt1d 12y ago
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."
tristor 12y ago
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.
ircuse 12y ago
Put that kind of suggestion in coderwall.com
pearjuice 12y ago
Stop using [commonly accepted, proven method] and use [obscure alternative] Textbook HN hit.
reidrac 12y ago
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 :)
prydonius 12y ago
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.
agopaul 12y ago
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 12y ago
  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 12y ago
    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
laumars 12y ago
> 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 12y ago
  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 12y ago
    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.
w4tson 12y ago
+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 12y ago
  I use tac file |less often to start at the end of the file..
amelius 12y ago
Why not just pipe the output of tail -f through less?
bmoresbest55 12y ago
This is pretty awesome. I have always thought that "tail -f" was a little limited but still useful. Any how, great post!
UserRights 12y ago
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...
jordanpg 12y ago
For something simple and very lightweight for Windows development, check out BareTail: http://www.baremetalsoft.com/baretail/ http://www.baremetalsoft.com/baretail/
BorisMelnik 12y ago
"here you have pretty much the same behavior" what is meant by 'pretty much?'
Animats 12y ago
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.
xxdesmus 12y ago
Imma just gonna leave this here: http://seclists.org/fulldisclosure/2014/Nov/74 http://seclists.org/fulldisclosure/2014/Nov/74
soyuka 12y ago
With `tmux` there is a visual mode that allows to `tail -F` with search, selection etc.
ewindisch 12y ago
I would be careful about such casual use of less: http://seclists.org/fulldisclosure/2014/Nov/74 http://seclists.org/fulldisclosure/2014/Nov/74
shirro 12y ago
Perhaps neovim with terminal mode and tail -F might be the best of all worlds.
ahomescu1 12y ago
I think I'll do the following (as a joke, surprised no one did it already): $ alias stalk='less +F'
r0naa 12y ago
Interesting. I always preferred watch -n 1 -d 'tail /path/to/log/file' to tail -f because of its nice highlighting feature.
- pimlottc 12y ago
  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.
jimmaswell 12y ago
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.
monokrome 12y ago
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.
decentrality 12y ago
Doesn't read ANSI color codes! Looking through manual for that.
- decentrality 12y ago
  SOLVED: less +F -R <file> Interprets color codes as RAW, relaying them to the screen as-is.
awalGarg 12y ago
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!
sbov 12y ago
For log files that move particularly fast, I prefer to use "watch tail -n 100" so I don't choke my connection.
sigzero 12y ago
Solaris 10 doesn't have the -F flag.
luckymedonwon 12y ago
Can you hack face book account
luckymedonwon 12y ago
Can I hack someone's pay face book
decentrality 12y ago
It would be awesome to remove the "Waiting for data... (interrupt to abort)" message.
- decentrality 12y ago
  Passing -Pw without a prompt at least gets that down to "... (interrupt to abort)"
fidz 12y ago
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
mdekkers 12y ago
...or use multi-tail
snambi 12y ago
wow... this is really a nice coomand
aweiher 12y ago
its not better for me, hitting enter is essential for me when using tail
fsniper 12y ago
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..

765 points by Pdincau 12y ago

Good share! Command line fu is always nice.

jaryd 12y ago

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.

_RPM 12y ago

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

TorKlingberg 12y ago
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.

jabo 12y ago

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 12y ago
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 12y ago
  Ah yes. I usually let the tail -f run, open another SSH session and grep from there.
mason55 12y ago
This only works if what you are searching for has scrolled past since you started following. If you want to see other occurrences in the file you're out of luck. For example, let's say you are watching to see which error message is generated when something goes wrong, then you want to see when else that error message has been thrown.

tikums 12y ago

Or use multitail. It supports syntax highlighting, among other features: http://www.vanheusden.com/multitail/ http://www.vanheusden.com/multitail/

drzaiusapelord 12y ago
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 12y ago
  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 12y ago
    That's really nice – thanks for the pointer. "ssh … varnishncsa | ccze" worked first time without any config, exactly as you'd want.
- smorrow 12y ago
  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.

scrame 12y ago

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

bch 12y ago
+1 (upvoted). $ less ./somefile /somesearch^M (<--- does a search) F (<--- puts less(1) in "follow mode", highlighting your previous search-term if it occurs in the future) (Edit: formatting)
- wampus 12y ago
  But how do you combine the two on the command line, so less is tailing the file AND highlighting a pattern when launched? I typically read logfiles with less +F, but it would be nice to create an alias for patterns in specific types of logs, so I don't have to remember them or rely on command history.
  - bch 12y ago
    $ less +F +/mypattern^M /my/file/to/search_and_follow * Note that I needed to "quote" (^V^M) that carriage-return to get the search pattern to work. Happy searching-and-following.
    - wampus 12y ago
      Thanks! Any idea what the quoted carriage return does? I wouldn't have thought of that in a million years.
      - 12y ago

nothrabannosir 12y ago

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

varikin 12y ago
This is my standard now. Logs rotate all the time and it very convenient to have tail continue working without my intervention.
pimlottc 12y ago
+1 for -F. Note that --follow and --retry are gnuisms, while -F works on most implementations of tail (even though it's not part of POSIX).
fweespeech 12y ago
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 12y ago
  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/
  - baq 12y ago
    c.f. tmux
  - fweespeech 12y ago
    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. :)

nmc 12y ago

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.

pimlottc 12y ago

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 12y ago
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.
- jimktrains2 12y ago
  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.
  - toddkaufmann 12y ago
    Use '/' (search) to enter a regexp to match a pattern on that line, and it will be highlighted.
    - lgas 12y ago
      This has nothing to do with what is being discussed in this subthread.
      - teraflop 12y ago
        Sure it does. If your log lines are distinct (e.g. they have timestamps or unique IDs) then you can use less's search highlighting to provide a visual marker for a specific line, similar to what you can do by manually inserting a bunch of blank lines on the console. This trick doesn't work if your log file has a bunch of identical lines and you want to keep an eye on their rate, though.

stonogo 12y ago

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 12y ago
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.
- yellowapple 12y ago
  Do you mean creating a new window every time you attach to an existing session? Or do you mean that each of those actions ("attach" and "create new window") should be atomic?
- vacri 12y ago
  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.
- philsnow 12y ago
  Depending on what you mean by "atomic" (do you really mean atomic, or do you just not want to have to type anything after you've attached to create the new window?), you can do this with screen's -X option. If that's what you want to do I can try to dig up the way I used to do this.

gitaarik 12y ago

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.

mattikus 12y ago
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.
nilkn 12y ago
I'd wager that 90% of the time that I'm using 'tail -F' I'm also piping it to grep.
- jfroma 12y ago
  This. I use: tail -f /var/log/x.log | grep foo -A 20 -B 20 Most of the time.
  - gitaarik 12y ago
    You know you can also do -C 40 for 40 lines of context instead of -A 20 -B 20
    - nkouevda 12y ago
      Note that -C is in each direction, not total; -C20 is equivalent to -A20 -B20.
      - jfroma 12y ago
        Thank you, This is the reason I always share how I do it in hn! LOL

pcwalton 12y ago

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

soyuka 12y ago
You should try vim dude.

orthecreedence 12y ago

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 12y ago
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.
simgidacav 12y ago
That's an important point: never use this trick with huge logs...

mrinterweb 12y ago

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.

spatz 12y ago

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

Florin_Andrei 12y ago
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.
haberman 12y ago
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 12y ago
  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 12y ago
    > 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

karlgoldstein 12y ago

Or just tail -f in an emacs buffer

VLM 12y ago
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 12y ago
  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.

oimaz 12y ago

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 12y ago
I imagine you could probably do "tail -f | grep/awk ... | less +F".
- simgidacav 12y ago
  It works fine indeed. I'm using it all the time.

jcfrei 12y ago

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 12y ago
As mentioned by others in this thread, you can use: "tail -F data.log"

emilsedgh 12y ago

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 12y ago
alias tf='tail -f' I saved you three more!
- le_lenny_face 12y ago
  GRUB_CMDLINE_LINUX_DEFAULT="init=/usr/bin/tail" Maximum savings!

igorgue 12y ago

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

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

64bitbrain 12y ago

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.

deleted 12y ago

[deleted]

zobzu 12y ago

U dont tell me what to do! i like my tail /thefox

nailer 12y ago

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 12y ago
I prefer the more expressive journalctl -fu service-name

tstack 12y ago

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.

kolme 12y ago

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.

thebouv 12y ago

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.

realrocker 12y ago

$make -j16 showcommands > build.log 2>&1 | less +F ctrl+c... <shit its not working> ctrl+c * 1e9 impatiently ... build stopped oops

ephexeve 12y ago

Nice!

sixothree 12y ago

Linux just really needs PowerShell.

zer0rest 12y ago
hahahaha, No.
- sixothree 12y ago
  Enjoy your parsing text files. I'll work with objects instead.
  - simgidacav 12y ago
    Eventually Microsoft will be able to reinvent Unix. Just keep the faith.
deleted 12y ago
[deleted]

jetpks 12y ago

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 12y ago
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.
- falcolas 12y ago
  Most terminals also offer searching capability, which do not result in disk seeks on the remote host.
- jetpks 12y ago
  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 12y ago
    Hmm, someone should add inotify handling to `less`.
Yizahi 12y ago
But it won't show me old parts of the log and I usually want this.

sciurus 12y ago

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 12y ago
That looks very nice! Thanks for the info. 8)

crypt1d 12y ago

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

tristor 12y ago

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.

ircuse 12y ago

Put that kind of suggestion in coderwall.com

pearjuice 12y ago

Stop using [commonly accepted, proven method] and use [obscure alternative] Textbook HN hit.

reidrac 12y ago

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 :)

prydonius 12y ago

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.

agopaul 12y ago

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 12y ago
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 12y ago
  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

laumars 12y ago

> 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 12y ago
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 12y ago
  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.

w4tson 12y ago

+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 12y ago
I use tac file |less often to start at the end of the file..

amelius 12y ago

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

bmoresbest55 12y ago

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

UserRights 12y ago

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

jordanpg 12y ago

For something simple and very lightweight for Windows development, check out BareTail: http://www.baremetalsoft.com/baretail/ http://www.baremetalsoft.com/baretail/

BorisMelnik 12y ago

"here you have pretty much the same behavior" what is meant by 'pretty much?'

Animats 12y ago

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.

xxdesmus 12y ago

Imma just gonna leave this here: http://seclists.org/fulldisclosure/2014/Nov/74 http://seclists.org/fulldisclosure/2014/Nov/74

soyuka 12y ago

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

ewindisch 12y ago

I would be careful about such casual use of less: http://seclists.org/fulldisclosure/2014/Nov/74 http://seclists.org/fulldisclosure/2014/Nov/74

shirro 12y ago

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

ahomescu1 12y ago

I think I'll do the following (as a joke, surprised no one did it already): $ alias stalk='less +F'

r0naa 12y ago

Interesting. I always preferred watch -n 1 -d 'tail /path/to/log/file' to tail -f because of its nice highlighting feature.

pimlottc 12y ago
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.

jimmaswell 12y ago

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.

monokrome 12y ago

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.

decentrality 12y ago

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

decentrality 12y ago
SOLVED: less +F -R <file> Interprets color codes as RAW, relaying them to the screen as-is.

awalGarg 12y ago

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!

sbov 12y ago

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

sigzero 12y ago

Solaris 10 doesn't have the -F flag.

luckymedonwon 12y ago

Can you hack face book account

luckymedonwon 12y ago

Can I hack someone's pay face book

decentrality 12y ago

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

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

fidz 12y ago

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

mdekkers 12y ago

...or use multi-tail

snambi 12y ago

wow... this is really a nice coomand

aweiher 12y ago

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

fsniper 12y ago

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