From c592a00f8f8c7e6baeff575a3762459173153635 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Thu, 8 Dec 2011 10:49:03 +0100 Subject: ls: be responsive to interrupts when color-listing large directories MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Starting with commit adc30a83, when using --color, ls inhibited interrupts to avoid corrupting the state of an output terminal. However, for very large directories, that inhibition rendered ls uninterruptible for too long, including a potentially long period even before any output is generated. * src/ls.c: Two phases of processing are time-consuming enough that they can provoke this: the readdir loop and the printing loop. The printing was supposed to be covered by a call to process_signals in (print_name_with_quoting): ... but that call was mistakenly guarded by a condition that might be false for many or even all files being processed. Call process_signals unconditionally. (print_dir): Also call process_signals in the readdir loop. * NEWS (Bug fixes): Mention it. Reported by Arkadiusz Miśkiewicz in http://bugs.gnu.org/10243 Co-authored-by: Eric Blake --- NEWS | 3 +++ 1 file changed, 3 insertions(+) (limited to 'NEWS') diff --git a/NEWS b/NEWS index de3888ddb..0d4c83b67 100644 --- a/NEWS +++ b/NEWS @@ -4,6 +4,9 @@ GNU coreutils NEWS -*- outline -*- ** Bug fixes + ls --color many-entry-directory was uninterruptible for too long + [bug introduced in coreutils-5.2.1] + ls's -k option no longer affects how ls -l outputs file sizes. It now affects only the per-directory block counts written by -l, and the sizes written by -s. This is for compatibility with BSD -- cgit v1.2.3-70-g09d2