Hello:
>2) You want "ctrl-c" to stop less from reading input and go into
> "view" mode, then press "F" to go back to "listening" mode? If
> so, what are these experiments with "SIGPIPE" trying to do?
this I have no problem obtaining with:
less -f <(long lived find command)
>1) less does not react to SIGINT before it receives any input.
> Actually, less (v487) does not react to SIGINT before it
> receives a full screen of input.
Yes I was looking for help about this issue. I understand now from yesterday's experiments and the help from the ml that less is the reason I can't kill the pipe when I press ctrl-c, since it eats the sigint before it has a full screen of input, as you pointed out. I would have liked to be able to trap the sigint and send a sigpipe to the session, thus killing both less and the long lived no-ouput-still find command. But it seems to me this is unachievable, since less must be the foreground process, and thus, if it eats the sigint, nothing can be done about it.
One experiment seemed for a moment a good solution, using unbuffer from expect package on less, but the less loses the ability to process interactive input.
So it seems that ctrl-z, kill % is the only solution that can be applied when less "hangs" waiting for more input and ignores ctrl-c, without resorting to using kill from other terminals.
The solution mentioned with =() I do use sometimes, but this was more of a "what about doing everything in memory" challenge; about the solutions with a pipe instead of process substitution I already investigated and I wasn't able to make it work, in particular I wasn't able to make the solutions with the trap on the first command to work, such as:
( trap "" INT; sleep 10; i=1; while true; do echo $i; i=$[i+1]; sleep 1; done ) | less
and the likes, I still get the
lines 1--1...skipping...
output and the need to use ctrl-z