tests/test-lib.sh (require_controlling_input_terminal_): Check stdout,
not stdin.
---
This testsuite bug causes the stty tests to be skipped, always, because
it's testing stdout, not stdin, and the testsuite engine redirects stdout
to a logfile. They still pass, despite not being run for lo these m
On 10 Feb 2009, Jim Meyering verbalised:
> FWIW, when I run "make check" on a F10 system, the 3 stty* tests
> are still skipped. However, when I run them individually, with
> your correction, they now _do_ PASS.
Interesting. They're run here (not an F10 system :) ).
FWIW I don't think pwd-unread
du/move-dir-while-traversing: boost the mkdir iteration count yet again.
---
tests/du/move-dir-while-traversing |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
I just had an FP in du/move-dir-while-traversing, due to the traversal
terminating too soon. My autobuilder is running on a
I just got this (from utimensat, not utimens, but they share a lot of
code) while doing a massively parallel 'make check' of coreutils 8.21 on
Linux 3.7.
The filesystem in question is ext4 atop loopback atop LVM atop md
(raid1), a fairly typical setup for coreutils test runs, I'd think. (The
sourc
On 26 Feb 2013, Paul Eggert verbalised:
> On 02/26/13 13:48, Nix wrote:
>
>> #2 0x004021e0 in test_utimens (print=print@entry=true,
>> func=0x401890 ) at test-utimens.h:35
>
> If that line number is right, the test program
> did a creat (file, 0600) that succ
On 26 Feb 2013, Paul Eggert outgrape:
> On 02/26/13 13:48, Nix wrote:
>
>> #2 0x004021e0 in test_utimens (print=print@entry=true,
>> func=0x401890 ) at test-utimens.h:35
>
> If that line number is right, the test program
> did a creat (file, 0600) that succ
