coreutils/tests/ls, branch v8.3Mirror of https://https.git.savannah.gnu.org/git/coreutils.git/
https://git.shady.money/coreutils/atom?h=v8.32010-01-01T13:06:47Zmaint: update all FSF copyright year lists to include 20102010-01-01T13:06:47ZJim Meyeringmeyering@redhat.com2010-01-01T09:56:28Zurn:sha1:1aa17dc89b3f313697661541adca0aa0defbdc09
Use this command:
git ls-files | grep -v COPYING \
| xargs env UPDATE_COPYRIGHT_USE_INTERVALS=1 \
build-aux/update-copyright
tests: readdir-mountpoint-inode avoid false-positive w/virtualbox2009-12-06T07:48:51ZJim Meyeringmeyering@redhat.com2009-12-05T16:41:28Zurn:sha1:d8cadda3b9b656870d54fe89dc94e72ecd496013
* tests/ls/readdir-mountpoint-inode: With some systems, stat can
succeed on a mount point and report that the inode number is 0.
Since ls displays "?" for those, that would otherwise show up as a
difference. Skip such mount points. Reported by Sergei Steshenko
in http://thread.gmane.org/gmane.comp.gnu.coreutils.bugs/19142
ls: fix capability coloring2009-11-09T08:16:20ZPádraig BradyP@draigBrady.com2009-11-08T03:45:27Zurn:sha1:10d97b31910b0030f7716474a48b3fc8e00dd216
Capability checking was incorrectly done on just the base name
rather than on the whole path. Consequently there could be both
false positives and negatives when coloring files with capabilities.
Also capability checking was not done at all in certain cases for
non executable files. Note passing absolute rather than relative
names to cap_get_file() reduces the has_capability() overhead
from around 33% to 30%. I.E. ls --color is now around 3% faster.
* src/ls.c (struct fileinfo): Add a has_capability member.
(print_color_indicator): Refactor to pass just a fileinfo pointer
and a flag to say if we're dealing with a symlink target.
(print_name_with_quoting): Likewise.
(gobble_file): Set has_capability in the fileinfo struct. Also do
a capability check even if executable coloring is disabled.
Ditto for SETUID and SETUID coloring.
Comment on how expensive has_capability() is.
(print_long_format): Adjust to refactored print_name_with_quoting.
(quote_name): Likewise.
(print_file_name_and_frills): Likewise.
* tests/ls/capability: Test the various false positive and negatives.
* THANKS: Add reporter (Ivan Labath).
* NEWS: Mention the fix.
tests: factor 350 fail=0 initializations into test-lib.sh2009-10-30T11:50:12ZJim Meyeringmeyering@redhat.com2009-10-30T09:50:21Zurn:sha1:3c88587b2eadee11413f4207abbbf13af07c438d
Run this command to remove the factored-out "fail=0" lines.
perl -ni -e '/^fail=0$/ or print' $(g grep -l '^fail=0$')
* tests/test-lib.sh: Initialize fail=0 here, not in 300+ scripts.
* tests/...: nearly all bourne shell scripts
Suggested by Eric Blake.
tests: abmon-align: avoid test failure2009-10-17T10:21:52ZJim Meyeringmeyering@redhat.com2009-10-17T10:18:54Zurn:sha1:527fb951def33fd76302e06f30e7221abd516ab6
* tests/ls/abmon-align: Don't remove (1d;) the first line of output.
That was making the test consider only 11 of 12 month names.
Rewrite not to use \(.*\), as that provoked a malfunction in GNU sed
on powerpc Mac OS X (though we don't know yet whether this is due to a
sed bug, or to miscompilation). Nelson Beebe reported the test failure.
ls: always print "?" for allocated size of a dereferenced dangling symlink2009-09-30T14:42:35ZPádraig BradyP@draigBrady.com2009-09-29T14:43:01Zurn:sha1:d4c7114bce116aefe28c899f5d0e7dcc39feb103
Previously for `ls -Ls` (but not `ls -Lsl`), we referenced
the st_blocks returned from the previous failed stat() call.
This undefined value was seen to be 0 for dangling symlinks at least.
* src/ls.c (print_file_name_and_frills, length_of_file_name_and_frills):
Don't use st_blocks if the previous stat() failed
* tests/ls/dangle: Add a test case
* NEWS: Mention the fix, and roll up related items into a single entry.
ls: print "?", not "0" as inode of dereferenced dangling symlink2009-09-29T09:42:45ZJim Meyeringmeyering@redhat.com2009-09-28T18:24:41Zurn:sha1:36edf7bad2ab76720a0bf6519074d23d4b8823a7
ls prints inode numbers two ways: for long (-l) listings,
and for short ones, e.g., ls -li and ls -i. The code to print
long listings properly printed "?" when the inode was unknown,
but the code for handling short listings would print 0 instead.
Factor out the formatting code into a new function so ls prints
the right string ("?") from both places:
* NEWS (Bug fixes): Mention it.
* src/ls.c (format_inode): New function.
(print_long_format): Use it here.
(print_file_name_and_frills): Use it here, too.
* tests/ls/dangle: Exercise this fix.
Reported by Yang Ren in http://bugzilla.redhat.com/525400
ls: with -LR, exit with status 2 upon detecting a cycle2009-09-29T05:28:39ZJim Meyeringmeyering@redhat.com2009-09-28T16:29:02Zurn:sha1:242689c7f93de72693979f877dd31b3ef7178eea
* src/ls.c (print_dir): Diagnosing the cycle is not enough.
Also set exit status to 2. This is what Solaris' /bin/ls does, too.
* tests/ls/infloop: Rework test: match both expected stdout and stderr.
Require an exit status of 2 in this case.
* doc/coreutils.texi (ls invocation): Mention that a loop provokes
in an exit status of 2.
* NEWS (Bug fixes): Mention it.
Reported by Yang Ren in http://bugzilla.redhat.com/525402.
* THANKS: Correct ordering of Yang Ren's names.
ls: handle disabling of colors consistently for all tile types2009-09-21T12:16:44ZPádraig BradyP@draigBrady.com2009-09-14T12:37:37Zurn:sha1:3a169f4c5d9159283548178668d2fae6fced3030
* src/ls.c (print_color_indicator): Use consistent syntax for
all file and directory subtypes, and fall back to the color
of the base type if there is no enabled color for the subtype.
This allows turning off specific colors for o+w dirs for example.
* tests/ls/color-dtype-dir: Add a case to test that turning off
coloring for o+w directories, falls back to standard dir color.
* NEWS: Mention the fix
Introduced by commit ac467814, 2005-09-05,
"Colorize set-user-ID ... files and sticky ... directories."
tests: ls/color-clear-to-eol: append NL to accommodate old sed2009-09-07T17:36:37ZJim Meyeringmeyering@redhat.com2009-09-07T17:36:21Zurn:sha1:9547a78bda1d4f01a782c869be248b5e0faf31f9
* tests/ls/color-clear-to-eol: Some vendor sed programs fail
to operate on lines that are not NL-terminated.
This affects at least Solaris 10's /bin/sed.
Reported by Pádraig Brady.