[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#24232: ls --color cannot be interrupted by a signal
From: |
Pádraig Brady |
Subject: |
bug#24232: ls --color cannot be interrupted by a signal |
Date: |
Mon, 15 Aug 2016 15:55:13 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 |
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