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

[Pádraig Brady]

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.
Do you get the delays with -U too?
I guess we should test over NFS too.

cheers,
Pádraig.