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

Previous Next

Full log

View this message in rfc822 format

From: Arkadiusz Miśkiewicz <arekm <at> maven.pl>
To: Pádraig Brady <P <at> draigbrady.com>
Cc: 10243 <at> debbugs.gnu.org, Jim Meyering <jim <at> meyering.net>
Subject: bug#10243: 8.14: ls --color is uninterruptible with ctrl+c (and no network fs in use)
Date: Wed, 7 Dec 2011 21:54:50 +0100

On Wednesday 07 of December 2011, Pádraig Brady wrote:
> On 12/07/2011 08:16 PM, Arkadiusz Miśkiewicz wrote:
> > On Wednesday 07 of December 2011, Pádraig Brady wrote:
> >> On 12/07/2011 05:56 PM, Jim Meyering wrote:
> >>> 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.
> >>> 
> >>> 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]);
> >> 
> >> Looks like a good fix.
> >> It works here and had negligible impact on performance.
> > 
> > That part works for me too. Unfortunately more changes is needed since
> > before printing happens it it still not possible to interrupt ls (and
> > for huge dirs it can take a while).
> > 
> > Moving code that enables special signal handling just before actuall
> > printing starts?
> 
> Probably, as long as there are no long blocking calls when
> processing large dirs, after we've starting printing.
Don't know why that should matter.

IMO before printing happens there should be no difference in signal handling 
behaviour between ls --color and ls (since the whole signal handling is just 
to "protect" printing from what I understand).

I was thinking about something like:
- do ususal things
- setup special signal handling
- print + process_signals () at print_name_with_quoting
- back to original signal handling
- do the rest of things

so most of the time there won't be any special signal handling (== will be the 
same as ls without --color).

> Do you get the delays with -U too?

Yes, too.

ls doesn't call process_signals() at all before printing starts in --color 
mode thus making ls uninterruptible in that period.

> I guess we should test over NFS too.

> cheers,
> Pádraig.


-- 
Arkadiusz Miśkiewicz        PLD/Linux Team
arekm / maven.pl            http://ftp.pld-linux.org/

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.