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.
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.
By the shell or by the kernel’s terminal discipline or by the terminal emulator? AFAIU the shell is basically out of the picture while `less` is running.
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.
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.
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.
I would say it's a bad UX and not just odd. I can't see any benefit to making it modal. It should just load new data as it becomes available without making the user do anything.
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.)
There's a way to make `^q` quit `less` and not clear the screen (like `less -X`), while `q` quits `less` and clears the screen (like normal `less`).
1. Do `echo '^q toggle-option -redraw-screen\nq' >> ~/.config/lesskey`
2. Make sure `less` is invoked without `-X` (or with `-+X` if you want to be sure).
This `^q` command is particularly useful for `git log` output and other things where you might need to refer back to them in the next terminal command you do. (In fact, `git` uses `less -FRX` by default, so you'd need to override its config to use `less -FR` instead for the above to work as intended). The `q` command is useful when you don't want to lose what you had on the screen before invoking `less`.
The original version I suggested works too, but by accident. `redraw-on-quit` is the actual option name.
(I'd edit my original message, but it's too late for that)
----
Also, note that if you put `--redraw-on-quit` into your `LESS` config (and not `-X`), and set up `^q` as above, things will still work but with flipped behavior of `q` and `^q`.
If your version of `less` is new enough, I believe that the `--redraw-on-quit` behavior is in every way (slightly) better than the `-X` behavior. In addition to the above, some terminals have special behaviors in alternate screen (like converting mouse wheel to up/down keys), which `--redraw-on-quit` will preserve.
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]
Maybe I missed it, is there no love for the piping to an external command?
I set a mark, move to somewhere else, then save the area between where I am and the mark: ma(assign mark "a" to position), jjj(move three lines away), |a(pipe from current-position to the "a" mark then a ! prompt appears so enter...) cat >somefile (which dumps the selected text, cur-pos to mark "a", into somefile).
That was great for saving snippets of news or emails.
Also, the -j setting. Sets the line position for searches so context is available, eg using -j8 means the search is 8 lines from the top of the screen.
I use the piping feature of less to add some interactivity to git-log.
When a commit is "selected" (at the top line of the screen), usually after a series of n/N, I can press a shortcut that invokes an action on this commit.
Currently, I use it for two things:
1. Running git-show on a commit I'm interested in. The cool thing is that once I quit the git-show's less, I'm back to where I was in git-log's less. They stack.
2. fixup-ing a commit, after verifying with the command from 1. that it really is the one I want. I've had enough problems with git-absorb and git-fixup that I prefer to do it myself.
I detect when a particular command is running[1] and set up keyboard shortcuts that send key sequences to less and ultimately lead to the top line of the screen being piped to a short script of mine that extracts the commit hash and does something with it.
[1]: via a debug trap in bash, which sets the terminal title, which, in turn, is detected by keyd-application-mapper; other setups are possible, I used to use tmux for that.
Don't forget that you can enable syntax highlighting/file rendering(like pdf, markdown) in less with lesspipe https://github.com/wofr06/lesspipe. It is exteremely useful and improves readability a lot. What's nice is that this functionality is typically disabled in pipes, so you can be sure that your script will behave as intended.
True. To combat that you can define a variable LESS with default options in your config file. In my case, I have export LESS='-R --quit-if-one-screen -i' (interpret escape sequences, cat input instead of showing it in a pager if it fits on a screen, enable smart-case searching)
Readit News
Less provides an alternative of <C-x> to stop following, but that is intercepted by most shells.
WoW, thanks a lot! That was my pain for many years. C-x works in Gnome Console just fine.
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.
This exists on IBM keyboards and is called 'Pause'. Sadly most programs don't use it.
I would say it's a bad UX and not just odd. I can't see any benefit to making it modal. It should just load new data as it becomes available without making the user do anything.
" ... 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 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.
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.)
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.
-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.)
1. Do `echo '^q toggle-option -redraw-screen\nq' >> ~/.config/lesskey`
2. Make sure `less` is invoked without `-X` (or with `-+X` if you want to be sure).
This `^q` command is particularly useful for `git log` output and other things where you might need to refer back to them in the next terminal command you do. (In fact, `git` uses `less -FRX` by default, so you'd need to override its config to use `less -FR` instead for the above to work as intended). The `q` command is useful when you don't want to lose what you had on the screen before invoking `less`.
(I'd edit my original message, but it's too late for that)
----
Also, note that if you put `--redraw-on-quit` into your `LESS` config (and not `-X`), and set up `^q` as above, things will still work but with flipped behavior of `q` and `^q`.
If your version of `less` is new enough, I believe that the `--redraw-on-quit` behavior is in every way (slightly) better than the `-X` behavior. In addition to the above, some terminals have special behaviors in alternate screen (like converting mouse wheel to up/down keys), which `--redraw-on-quit` will preserve.
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...
I set a mark, move to somewhere else, then save the area between where I am and the mark: ma(assign mark "a" to position), jjj(move three lines away), |a(pipe from current-position to the "a" mark then a ! prompt appears so enter...) cat >somefile (which dumps the selected text, cur-pos to mark "a", into somefile).
That was great for saving snippets of news or emails.
Also, the -j setting. Sets the line position for searches so context is available, eg using -j8 means the search is 8 lines from the top of the screen.
When a commit is "selected" (at the top line of the screen), usually after a series of n/N, I can press a shortcut that invokes an action on this commit.
Currently, I use it for two things:
1. Running git-show on a commit I'm interested in. The cool thing is that once I quit the git-show's less, I'm back to where I was in git-log's less. They stack.
2. fixup-ing a commit, after verifying with the command from 1. that it really is the one I want. I've had enough problems with git-absorb and git-fixup that I prefer to do it myself.
I detect when a particular command is running[1] and set up keyboard shortcuts that send key sequences to less and ultimately lead to the top line of the screen being piped to a short script of mine that extracts the commit hash and does something with it.
[1]: via a debug trap in bash, which sets the terminal title, which, in turn, is detected by keyd-application-mapper; other setups are possible, I used to use tmux for that.
(I usually invoke this when viewing jq output, a JSON data formatter / query tool.)