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.
