no test suite addition [was: ls --color is uninterruptible with ctrl+c

[Jim Meyering]

Jim Meyering wrote:
...
> Subject: [PATCH] ls: be responsive to interrupts when color-listing large
>  directories
>
> 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.
...
> ---
>  NEWS      |    3 +++
>  THANKS.in |    1 +
>  src/ls.c  |    7 ++++++-

Note the lack of a test suite addition.

In coreutils development, the requirement for a test suite
addition for each bug fix is well established.  However, in this
case, it's clear that testing this fix portably would be a big job.

One possibility is to run "ls --color big-dir" under expect or some
perl/python equivalent, where big-dir has enough entries that we have
a good chance of detecting the "big-dir:" output and then sending
an interrupt before the following readdir loop completes.  Making that
work on everything from spinning rust to SSDs and tmpfs might be hard.

While Pádraig and I were chatting about this, he realized that it'd be
feasible to test if we had a FUSE-based file system for which readdir
is consistently slow, e.g., with a brief sleep.  Then we could
enlarge the window with a moderately-sized directory and still
be able to generate (w/high probability) an interrupt while the
readdir loop is still running.

There are even perl- and python-driven FUSE implementations:

 http://cpansearch.perl.org/src/NOSEYNICK/Fuse-Simple-1.00/README
 http://sourceforge.net/apps/mediawiki/fuse/index.php?title=FUSE_Python_tutorial

A minor caveat with that approach is that the test would have to be run
as root, or as member of a group that can mount the target file system.

If anyone can think of an easier way to reliably script a test for this,
please let us know.