4

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
Pierre Lebeaupin
  • 311

1 Answers1

5

The solution is in fact to use ctrl-C, but simultaneously make sure the resulting signal is not sent to the other command(s) that pipe to less. That was the decisive insight I failed to initially get: while only less performs reads from the terminal, so ordinary input makes it to that command only, a signal originating from the terminal driver, on the other hand, is dispatched to all processes in the pipeline.

Controlling signal dispatch in this way is easier said than done. To the best of my knowledge, there is no good solution, so I'm presenting the least bad one: use setsid(1) to isolate the other commands to their own session:

% setsid sh -c "/bin/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 ; /bin/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; /bin/echo baz" sh-c | less

With this setup, when I hit ctrl-C I get the expected behaviour: the less prompt appears just after what it could receive before the sleep and I can browse back to everything before that, and when I direct to get back to the latest content, the last of it (baz, here) eventually shows up. By stuffing content production to its own session, I shield that process from the signal (that I need to involve in order to interrupt the reading operation in which less would otherwise be stuck).

The main catch is that setsid(1) is completely nonstandard; while all Unix and Unix-like kernels support the setsid(2) syscall, its availability as a standalone command is something of a Linux-ism. If it isn't available on your install, your favorite package manager ought to provide it (the source is simple and in the public domain), either by itself or as part of a util-linux package:

% brew install util-linux # MacOS

Don't be misled by the name: setsid(1), at least, is portable. (Note: the util-linux cask from Homebrew shown here is keg-only, i.e. nothing is installed in the search paths because of collisions; you will have to manually add its bin directory to $PATH)

Pierre Lebeaupin
  • 311
  • That sleep 5 at the start was bothering me, so I looked at ways to fix that. Here is what I found: Linux actually avoid the issue I mention on MacOS in a rather heavy-handed way: opening a FIFO for writing (without reading) blocks until someone else has the same FIFO open for reading, thus delaying the writes that could otherwise have been subject to SIGPIPE. So this solves the issue, but such rendez-vous-based synchronization is almost always problematic: for instance, if I needed to involve multiple FIFO, I would need to remember to open them in the same order, or I will deadlock. – Pierre Lebeaupin Feb 20 '23 at 00:52
  • But involving multiple FIFO is not (yet) the issue here. Since Linux also blocks opening a FIFO for reading only until someone else has it open for writing (MacOS also does that, but not the converse), the combination of the two behaviors means you can't do the two operations in succession! Even in a single command! You need to perform the two opens (>fifo and < fifo) in two parallel branches, the background and the foreground ones; but then you risk synchronization issues on other platforms. We definitely want to avoid examples that work on one platform but break unpredictably elsewhere. – Pierre Lebeaupin Feb 20 '23 at 01:00
  • To obviate such cross-platform mismatches, portable scripts will open the FIFO while execution is still serial, but do so in a read-write manner, which never blocks. But this is incompatible with defensive programming: I definitely don't want my command to think it could read from the fil descriptor provided. Worse, if less is provided with such a file descriptor, it will never recieve an end of file status… as there is still a writer left: itself. – Pierre Lebeaupin Feb 20 '23 at 01:08
  • In the end, I did find various workarounds to obtain the behavior I wanted, but they are all so ugly that I would rather stick with the sleep 5 until I have improved one of them to be acceptable. – Pierre Lebeaupin Feb 20 '23 at 01:12
  • For posterity, here is the solution I initially found for controlling signal dispatch: have the command of interest run in the background and have it write to a FIFO (named pipe), and have less open that: (sleep 5; ( 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 ) > fifo ) & less < fifo As you can see, there is one complication… – Pierre Lebeaupin Feb 20 '23 at 22:02
  • In MacOS (and other descendants of the BSD family tree, presumably) you can't start writing to a FIFO (or possibly even just open it for writing) until it has also been opened for reading, or your writer process will get hit with a SIGPIPE… In some way, that makes sense, though I'd prefer if that signal were raised only in cases where there used to be such a reader, but now no longer is. To avoid the SIGPIPE, I insert a sleep to delay the opening for and writing to the FIFO until less itself is ready. – Pierre Lebeaupin Feb 20 '23 at 22:02
  • Additional note: using sh -m rather than setsid sh will not work for our purposes (I tried): the former "only" creates a process group, which is not what matters for signal delivery purposes, as the new process group is still part of the session controlled by the terminal. The stronger setsid is needed. – Pierre Lebeaupin Feb 20 '23 at 22:44