I will occasionally use the pickaxe functionality of
git to locate changes of interest. This can be quite slow, obviously (the same would apply to, say,
hg grep), but more significantly it is bursty: a few results clumped together, separated by inactivity.
For these reasons, I try and read the results as they come, in practice by piping the output to
less (in fact, this is what
git does by default): when a burst comes, you can't possibly hit
ctrl-S fast enough for the software flow control functionality to be useful these days.
But I often hit a… behaviour of
less where if I scroll enough that even just one line of content to show on screen has yet to come out of the
less gets stuck on that and I lose its prompt and most ways to control it, until more content comes. Now, I understand why it happens, but if that was the behaviour of a shell command, I'd use
ctrl-Z to recover a prompt (and then do
bg). Is there an equivalent in
less to recover the pager prompt?
In this situation,
ctrl-Z is useless: Unix job control is inappropriate for commands that manage the screen contents. Besides, I don't want to get back to the shell prompt anyway: typically, what I want to do is check back something I might have glimpsed while I was repeatedly hitting the space bar, so I don't want to leave less.
Ctrl-C is also useless: while it does allow me to recover a prompt, this will additionally result in the received content being frozen; that is, when my curiosity is satisfied and I try and get back to the latest content (with a few taps of the space bar, or
G, etc.), nothing more than what I had comes up, no matter how long I wait. Even with
tail -f mode).
I use this command to simulate the
(echo -e 'foo\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n.' ; sleep 3 ; echo -e 'bar\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n.' ; sleep 10; echo baz) | less