bug-coreutils
[Top][All Lists]
Advanced

[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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]