bug#10243: 8.14: ls --color is uninterruptible with ctrl+c (and no network fs in use)

[Jim Meyering]

Arkadiusz Miśkiewicz wrote:
> When doing "ls --color=tty" or "ls --color=auto" on directory then ls ignores
> (?) ctrl+c or ctrl+z signals. Basically I'm unable to interrupt ls in such
> case. Easily reproducible with bigger directories.
>
> # ls --color=tty
> ^C^C^C^C^C^C^C^C^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z
> (no reaction)
>
> There is no such problem if ls is being straced (strace -f -F -s 200 ls) at
> that time or if pipe is used ("ls --color=tty | less") - in such cases ctrl+c
> works immediately. If --color is not used then there is no problem, too.
>
> First I thought that this is filesystem issue but it is not. One of xfs
> filesystem developers was also able to reproduce the problem and confirm that
> most likely ls is doing something incorrect.
>
> # LC_ALL=C ls --version
> ls (GNU coreutils) 8.14
> Copyright (C) 2011 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
>
> Written by Richard M. Stallman and David MacKenzie.
>
> Linux 3.0.9, glibc 2.14 here.

Thanks for the report.
I reproduced it starting in an empty directory like this:

    seq 100000|xargs touch
    env ls --color -1

and tried to interrupt that.
Failed to interrupt every time.

Here's one way to fix it:

diff --git a/src/ls.c b/src/ls.c
index 8be9b6a..58bb196 100644
--- a/src/ls.c
+++ b/src/ls.c
@@ -4060,9 +4060,9 @@ print_name_with_quoting (const struct fileinfo *f,
   if (stack)
     PUSH_CURRENT_DIRED_POS (stack);

+  process_signals ();
   if (used_color_this_time)
     {
-      process_signals ();
       prep_non_filename_text ();
       if (start_col / line_length != (start_col + width - 1) / line_length)
         put_indicator (&color_indicator[C_CLR_TO_EOL]);