emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[debbugs-tracker] bug#24232: closed (ls --color cannot be interrupted by


From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#24232: closed (ls --color cannot be interrupted by a signal)
Date: Tue, 06 Sep 2016 16:00:02 +0000

Your message dated Tue, 6 Sep 2016 16:59:08 +0100
with message-id <address@hidden>
and subject line Re: bug#24232: [PATCH] ls: postpone installation of signal 
handlers
has caused the debbugs.gnu.org bug report #24232,
regarding ls --color cannot be interrupted by a signal
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden)


-- 
24232: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=24232
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: ls --color cannot be interrupted by a signal Date: Mon, 15 Aug 2016 15:55:04 +0200 User-agent: KMail/4.14.10 (Linux/4.7.0-gentoo; KDE/4.14.20; x86_64; ; )
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.

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

Kamil



--- End Message ---
--- Begin Message --- Subject: Re: bug#24232: [PATCH] ls: postpone installation of signal handlers Date: Tue, 6 Sep 2016 16:59:08 +0100 User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
On 06/09/16 16:38, Kamil Dudka wrote:
> ... until they are actually needed.  That is right before the first
> escape sequence is printed to a terminal.

Cool, that's a good improvement.
Note I moved the NEWS from "bugs" to "improvements".
Also I tweaked a long line to avoid `make syntax-check` failure.

Will push later.

thanks!
Pádraig



--- End Message ---

reply via email to

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