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 git
command, 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 F
(tail -f
mode).
I use this command to simulate the git
behaviour:
(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