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
