181–190 of 211 posts
The problem is that less +F polls every second while tail -f uses inotify, which is both more efficient and responds faster to change.
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.
Earlier quoted context omitted.
on OpenBSD -f does: Do not stop when end-of-file is reached, but rather to wait for additional data to be appended to the input. If the file is re- placed (i.e., the inode number changes), tail will reopen the file and continue. If the file is truncated, tail will reset its position to the beginning. This makes tail more useful for watching log files that may get rotated. The -f option is ig- nored if the standard in…
Is there a bug report open for that yet? FreeBSD has this so they should be able to resync easily enough
"For f***** sake! I should have used '-F'! Arghhh...!"
+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 '…
Earlier quoted context omitted.
An example of some of the vi commands that less(1) has adopted. You can also: * page forward and backward, including using numeric prefixes to indicate a lineno or indicate "repeat 'n' times". * launch vi if less(1) is working on a file (versus (eg) stdout of some process) * search fwd/backward * start examining a new file w/o leaving less(1) * ...
Another less-vs-vi question: As a junior programmer I got chewed out by my IT department because I was examining a (production) log file in vi. The sysadmin told me I should use less (actually more---this was on Solaris in ~2001). To this day I only read log files with less, but I've never figured out his objection. Negatives to using vi I can imagine are: - I might write to the log file. That seems like a real worry…
1) for user: less chance (pun intended) to actually change the file when all you wanted was to read it
2) for sysadmin: if sysadmin sees "less somefile.log" in bash history, he knows the user just read the log. If he sees "vi somefile.log" then he doesn't know if the user has also changed the log file (maybe not even knowing it).
The assumption is that you deal with non-malicious users who just make mistakes (which is often the case).
Earlier quoted context omitted.
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.
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…
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?
> 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…
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.
apt-get install tmux