Re: coreutils inaccessible test fails on HP-UX with CVS build

2006-06-16 Thread Jim Meyering
[EMAIL PROTECTED] (Bob Proulx) wrote: Building CVS corutils on HP-UX 11.11 produces the following test failure for the inaccessible test. It is expected to fail. But it is expected to fail with a different message. I am not sure what the best way to handle differences such as this. ...

Re: filutils 4.1

2006-06-16 Thread goesh
Thanks guys, i appreciate your comments back.  I understand that apparently there are other ways, many much simpler, to do what I have done inside ls.c, however, I like it in ls.c, it's convienent.  Almost any conceivable use of ls can be combined with my new -Z switch, making it convienent to

Re: filutils 4.1

2006-06-16 Thread Paul Eggert
Jim Meyering [EMAIL PROTECTED] writes: find $PWD/* -printf '%A@ %p\n'|sort -nr Wow, learn something every day. Thanks. Alas, though, this mishandles files whose time stamps differ only in the subsecond parts, whereas 'ls' by itself would get it right. Looks like 'find' is another program

Re: ia64 GNU/Linux pwd-long test failure in CVS coreutils

2006-06-16 Thread Paul Eggert
Thanks, Andreas. I have filed this as a Debian bug (against glibc) here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=373930 A possible workaround for coreutils is to use a path of more than 16384 bytes in length for the test, rather than just more than 4096 -- this is according to Aurelian

Re: filutils 4.1

2006-06-16 Thread James Youngman
On 6/16/06, Paul Eggert [EMAIL PROTECTED] wrote: Jim Meyering [EMAIL PROTECTED] writes: find $PWD/* -printf '%A@ %p\n'|sort -nr Wow, learn something every day. Thanks. Alas, though, this mishandles files whose time stamps differ only in the subsecond parts, whereas 'ls' by itself would

Re: ia64 GNU/Linux pwd-long test failure in CVS coreutils

2006-06-16 Thread Jim Meyering
Paul Eggert [EMAIL PROTECTED] wrote: Thanks, Andreas. I have filed this as a Debian bug (against glibc) here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=373930 A possible workaround for coreutils is to use a path of more than 16384 bytes in length for the test, rather than just more

sleep args

2006-06-16 Thread Dan Jacobson
Could check for e.g., sleep 4 5 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils

[Chet Ramey] Re: current input line lost on ^Z

2006-06-16 Thread Dan Jacobson
bug-bash@gnu.org item related to cat? Dan Jacobson wrote: Perhaps bad? $ cat p bb ccc^Z $ something_else $ fg zzz ^D $ cat pr bb zzz I was not finished composing line ccc when I had to do something_else. Now I have to remember what I was

Re: sleep args

2006-06-16 Thread Jim Meyering
Dan Jacobson [EMAIL PROTECTED] wrote: Could check for e.g., sleep 4 5 Sorry, but that's legitimate usage, so wouldn't want to give a diagnostic about it. You can currently say sleep 5h 3m 20s. And sleep 4 5 is equivalent to sleep 9. Other implementations (e.g., solaris) work the same way.

Re: sleep args

2006-06-16 Thread Eric Blake
Could check for e.g., sleep 4 5 This is a well-defined extension of GNU sleep; it is equivalent to sleep 9. GNU adds its arguments, so that you can do, for example, 'sleep 1m 30s' to sleep for 90 seconds. However, it does raise the point that sleep does not like negative numbers, even though

Re: [Chet Ramey] Re: current input line lost on ^Z

2006-06-16 Thread Eric Blake
C Nothing to do with bash. Depends on how the cat process reacts to the C SIGTSTP and whether or not the terminal driver even lets cat see the C partial line, since it's running in cooked mode. Nor does it have anything to do with cat. It is your terminal driver that is eating the