Surprised they missed follow! It’s a bit odd to use, but once you get used to it it’s better than tail in many circumstances IMO. `less +F` starts less following stdin or whatever file argument you’ve provided. <C-c> breaks following, allowing you to search around a business-as-usual `less` session. Hitting `F` (that’s uppercase) starts following again. Yes, you can just start following within a session with `F` too if you forgot to add +F to the `less` invocation.
With `tail` you can press enter a few times to put some empty lines after the last line. This is useful e.g. when you trigger a function multiple times and want to easily see line groups from each attempt. It's the only reason I still use `tail` for following when `less` is available.
A visual mark would be nice, agreed. I haven't tried it, but I wonder if you could approximate it with the bookmarking feature that less(1) does have. It wouldn't be visible, but it would scroll to a consistent mark.
I usually use tail when I need to do some ad-hoc log following.
Having to set bookmarks and remember them is a PITA I can usually do without. If I'm looking at "normal" log output, it's usually set up in a nice aggregator somewhere, where I can easily exclude noise and otherwise uninteresting output.
Maybe OT, but I thought for a long time that "follow" was some sophisticated file descriptor trickery that required you to somehow "stream" the file while reading and would therefore be incompatible with opening a file "normally".
My mind was blown when finding out its really just "keep on polling after EOF". Meaning there is absolutely no difference between opening a file normally and "following" a file - and software could easily switch between the two "modes" on the fly.
If you're following a pipe (such as `kubectl logs | less +F`), <C-c> is sent to all processes in a pipeline, so it stops less from following and it stops the other process entirely. Then you can't start following again with F, or load more data in with G.
Less provides an alternative of <C-x> to stop following, but that is intercepted by most shells.
It would be nice to have a mode that follows in the sense of automatically picking up new output, but that simultaneously would let you navigate around, similar to how terminals behave. Then you’d only need an autoscroll toggle for when you’re at the bottom.
And combined with -E, it'll quit immediately if the output is smaller than the terminal size.
...And combined with some of the other options in the post, my go-to has been "less -SEXIER" for a long time. Specifying E twice doesn't seem to do anything except make this easier to remember.
I recommend -FX instead of -EX. They both quit immediately if the output is smaller than the screen size, but -FX does not quit if the output is larger and you jump to the end of a large file, so you can continue to do things like scroll back or search.
git uses "less -FRX" by default. This is how I learned about -F.
(To be pedentic, git uses "LESS=FRX less", which accomplishes the same thing.)
I hate -E. Quitting immediately does not do good things to my muscle memory. I’m using to hitting q to quit less when I am done. Now the q key becomes part of the input to the shell prompt (or worse if there’s a different tool invoking less and now q might be interpreted differently by that tool). I value the consistency of user interaction more than saving a keystroke.
The tip that I've been using quite a lot lately by debugging long log files is using `&` to filter what I want to read and `&!` to filter-out what's not useful (and they support regexes).
Admittedly, they are a bit slow sometime and sure, you could use `grep -v` then pipe which is way faster, but they've saved me on removing noise from logfiles from time to time when you don't always know what to filter beforehand :).
-L: skip preprocessing the input file. When opening rotated log files with the names like logfile.1, logfile.2... the default preprocessor on some distros will recognize them as man page source and helpfully pipe through nroff. If the file is largish this introduces an annoying pause. Using -L skips all that.
Ctrl-R as the first character of a search string will search for that literal string, not the regular expression. Nice if you have regex metacharacters in the search string and don't want to bother with escaping (and don't need the regex facilities, of course.)
I have a single line in my config[1] which binds s to back-scroll, so that d and s are right next to each other and I can quickly page up/down with one hand.
If you’re on macOS, you may not be able to use this unless you install less from Homebrew, or otherwise replace the default less.[2]
I came here to suggest the same! It's incredibly handy and I use it all the time at work: there's a process that runs for a very long time and I can't be sure ahead of time if the output it generates is going to be useful or not, but if it's useful I want to capture it. I usually just pipe it into `less` and then examine the contents once it's done running, and if needed I will use `s` to save it to a file.
(I suppose I could `tee`, but then I would always dump to a file even if it ends up being useless output.)
If a script running as root uses less (or vi), just do "!bash" and you have a root shell. Note that systems that let you do this are usually pretty weak, and there are often many other ways to get root access, but this is a particularly simple one that I used a few times in the past.
Some of these come intuitively when you know how to use vim. I expect to be able to search when pressing / in terminal programs, just like I expect Ctrl+F to work in GUIs.
There -R to quit if the file is less than the screen size. There's also most as an alternative pager, and also glow (of course which, my fork of it is better) to render md files in the terminal.
Surprised they missed follow! It’s a bit odd to use, but once you get used to it it’s better than tail in many circumstances IMO. `less +F` starts less following stdin or whatever file argument you’ve provided. <C-c> breaks following, allowing you to search around a business-as-usual `less` session. Hitting `F` (that’s uppercase) starts following again. Yes, you can just start following within a session with `F` too if you forgot to add +F to the `less` invocation.
With `tail` you can press enter a few times to put some empty lines after the last line. This is useful e.g. when you trigger a function multiple times and want to easily see line groups from each attempt. It's the only reason I still use `tail` for following when `less` is available.
A visual mark would be nice, agreed. I haven't tried it, but I wonder if you could approximate it with the bookmarking feature that less(1) does have. It wouldn't be visible, but it would scroll to a consistent mark.
I usually use tail when I need to do some ad-hoc log following.
Having to set bookmarks and remember them is a PITA I can usually do without. If I'm looking at "normal" log output, it's usually set up in a nice aggregator somewhere, where I can easily exclude noise and otherwise uninteresting output.
Maybe OT, but I thought for a long time that "follow" was some sophisticated file descriptor trickery that required you to somehow "stream" the file while reading and would therefore be incompatible with opening a file "normally".
My mind was blown when finding out its really just "keep on polling after EOF". Meaning there is absolutely no difference between opening a file normally and "following" a file - and software could easily switch between the two "modes" on the fly.
If you're following a pipe (such as `kubectl logs | less +F`), <C-c> is sent to all processes in a pipeline, so it stops less from following and it stops the other process entirely. Then you can't start following again with F, or load more data in with G.
Less provides an alternative of <C-x> to stop following, but that is intercepted by most shells.
It would be nice to have a mode that follows in the sense of automatically picking up new output, but that simultaneously would let you navigate around, similar to how terminals behave. Then you’d only need an autoscroll toggle for when you’re at the bottom.
Take a look at "lnav" ...
I'm so mad that I didn't know the hitting F thing!
Also -X or --no-init
" ... desirable if the deinitialization string does something unnecessary, like clearing the screen."
I prefer to not clear the screen. I usually want to continue to refer to something or even copy/paste from the content to my current command line.
And combined with -E, it'll quit immediately if the output is smaller than the terminal size.
...And combined with some of the other options in the post, my go-to has been "less -SEXIER" for a long time. Specifying E twice doesn't seem to do anything except make this easier to remember.
I recommend -FX instead of -EX. They both quit immediately if the output is smaller than the screen size, but -FX does not quit if the output is larger and you jump to the end of a large file, so you can continue to do things like scroll back or search.
git uses "less -FRX" by default. This is how I learned about -F.
(To be pedentic, git uses "LESS=FRX less", which accomplishes the same thing.)
I'm reading it correctly that it will cause less to exit if you scroll until the end of file even if the file is larger than the terminal size?
Yeah; in both cases (text is larger or smaller than terminal) it makes "less" act the same as "more" with auto-exiting.
I hate -E. Quitting immediately does not do good things to my muscle memory. I’m using to hitting q to quit less when I am done. Now the q key becomes part of the input to the shell prompt (or worse if there’s a different tool invoking less and now q might be interpreted differently by that tool). I value the consistency of user interaction more than saving a keystroke.
The tip that I've been using quite a lot lately by debugging long log files is using `&` to filter what I want to read and `&!` to filter-out what's not useful (and they support regexes).
Admittedly, they are a bit slow sometime and sure, you could use `grep -v` then pipe which is way faster, but they've saved me on removing noise from logfiles from time to time when you don't always know what to filter beforehand :).
EDIT: It was in TFA.
Two things that have helped me a lot of times:
-L: skip preprocessing the input file. When opening rotated log files with the names like logfile.1, logfile.2... the default preprocessor on some distros will recognize them as man page source and helpfully pipe through nroff. If the file is largish this introduces an annoying pause. Using -L skips all that.
Ctrl-R as the first character of a search string will search for that literal string, not the regular expression. Nice if you have regex metacharacters in the search string and don't want to bother with escaping (and don't need the regex facilities, of course.)
Less can be configured with a ~/.lesskey file
I have a single line in my config[1] which binds s to back-scroll, so that d and s are right next to each other and I can quickly page up/down with one hand.
If you’re on macOS, you may not be able to use this unless you install less from Homebrew, or otherwise replace the default less.[2]
[1] https://github.com/jez/dotfiles/blob/master/lesskey#L2
[2] https://apple.stackexchange.com/questions/27269/is-less1-mis...
You can also press `s` to save data from a pipe to a file rather than manually copy pasting.
I came here to suggest the same! It's incredibly handy and I use it all the time at work: there's a process that runs for a very long time and I can't be sure ahead of time if the output it generates is going to be useful or not, but if it's useful I want to capture it. I usually just pipe it into `less` and then examine the contents once it's done running, and if needed I will use `s` to save it to a file.
(I suppose I could `tee`, but then I would always dump to a file even if it ends up being useless output.)
> I've got more less tips than the Bible's got Psalms
But there are (at least) 150 Psalms! You're going to need more less tips to match that.
> The ! lets you invoke an external command.
Also useful for privilege escalation...
If a script running as root uses less (or vi), just do "!bash" and you have a root shell. Note that systems that let you do this are usually pretty weak, and there are often many other ways to get root access, but this is a particularly simple one that I used a few times in the past.
I like less and found that https://github.com/noborus/ov can be a good modern alternative to it.
Another nice one is moor (née moar): https://github.com/walles/moor
Looks cool! Annoyingly less sometimes bugs out and starts spinning, have to kill it from the outside.
Some of these come intuitively when you know how to use vim. I expect to be able to search when pressing / in terminal programs, just like I expect Ctrl+F to work in GUIs.
There -R to quit if the file is less than the screen size. There's also most as an alternative pager, and also glow (of course which, my fork of it is better) to render md files in the terminal.
Oh I see what you mean about glow, that looks like a nice UX improvement - I'm going to try your fork.
https://github.com/charmbracelet/glow/compare/master...fragm...
s/assorted/useful/