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

[Arkadiusz Miśkiewicz]

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?

> 
> cheers,
> Pádraig.


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