Subject: bug#24232: ls --color cannot be interrupted by a signal

From: Pádraig Brady <[email-masked]>
Date: Mon, 15 Aug 2016 15:55:13 +0100

On 15/08/16 14:55, Kamil Dudka wrote:
> If 'ls --color' outputs to a terminal and a syscall blocks (e.g. while reading 
> a directory from unresponsive network file system), it cannot be interrupted 
> by a signal.
> 
> This seems to be caused by the code of ls, which sets the SA_RESTART flag on 
> terminating signals.  A possible solution would be to reset the flag prior to 
> calling certain blocking syscalls and process the signals synchronously in an 
> EINTR loop.

Sounds expensive

> Alternatively, we can document this behavior as intended (or broken by design) 
> and suggest users to disable color output or redirect the output off terminal 
> to work around the issue.
> 
> Any other idea how to solve it?
> 
> Originally reported at: https://bugzilla.redhat.com/1365933

The signal catching functionality originated trying to restore terminal color:
http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v4.5.3-89-g8549068

That was adjusted to only outputting reset chars once for multiple signals,
http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v5.2.1-357-geae1b7f

and not outputting reset chars at arbitrary places as that messes up multi-byte chars:
http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v5.2.1-368-gadc30a8

Maybe we should just buffer internally at put_indicator (&color_indicator[C_LEFT]);
and output only at put_indicator (&color_indicator[C_RIGHT]) or equivalent.
That wouldn't introduce significant overhead I think.

Pádraig