GNU bug report logs -
#24232
ls --color cannot be interrupted by a signal
Previous Next
Reported by: Kamil Dudka <kdudka <at> redhat.com>
Date: Mon, 15 Aug 2016 13:56:01 UTC
Severity: normal
Done: Pádraig Brady <P <at> draigBrady.com>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
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
This bug report was last modified 8 years and 338 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.