Arch Linux

Description: When there is a bash handler for SIGCHLD, lesspipe is stopped when the process emptying into the pipe finishes. This problem might be able to be fixed by making lesspipe create a named pipe (i.e., with "mkfifo") rather than simply dumping into a temporary file.

Additional info:
* lesspipe 1.70-4
* Have also e-mailed the author

Steps to reproduce:

1. Put this simple script into .bashrc (e.g., for telling bash the proper window width after a resize so that commands always wrap correctly):

#####################################
sizetw 26 100
function updwin() {
NUMLINES=$(tput lines)
NUMCOLS=$(tput cols)
sizetw ${NUMLINES} ${NUMCOLS}
return 0
}
trap updwin SIGWINCH
trap updwin SIGCHLD
#####################################

2. Then, after starting a new bash shell that executes that script, try:

# cat /etc/services | less

(with lesspipe installed and LESSOPEN set properly).


3. less should pause on the first page. After a few seconds, hit the "down" cursor to move down in the file. bash should then report that the process was "Stopped" (which can be confirmed with the "jobs" command). The user then has to issue a "fg" to get the process back and quit the less.


I speculate that lesspipe.sh is redirecting all output to a temporary file. That allows piped processes to end early, which triggers the SIGCHLD. If lesspipe used a named pipe (i.e., a file made with "mkfifo") instead, it would not only save space on the disk, but the source of less's piped input should stay open as it blocks waiting for the fifo to hit its end of file.