Re: coreutils inaccessible test fails on HP-UX with CVS build
[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. ... rm: unable to record current working directory: Permission denied --- rm: cannot remove `rel': Permission denied + exit 1 + exit 1 + status=1 + cd /usr/local/build/coreutils/hppa-hpux11.11-gcc-coreutils/build/tests/rm + chmod -R u+rwx inaccessible.tmp + rm -rf inaccessible.tmp + exit 1 FAIL: inaccessible Hi Bob, Thanks for reporting that. On HP-UX, rm has to use a different code path for that case, since the system provides neither openat-like functions, nor a /proc/self/fd-like way to emulate them. Does this patch solve the problem? Index: inaccessible === RCS file: /fetish/cu/tests/rm/inaccessible,v retrieving revision 1.4 diff -u -p -r1.4 inaccessible --- inaccessible28 May 2006 12:11:35 - 1.4 +++ inaccessible16 Jun 2006 06:11:29 - @@ -44,6 +44,10 @@ EOF # to the expected one: sed 's/: The file access permissions.*/: Permission denied/'outo1;mv o1 out +# HP-UX 11.11 goes a different route, too. +# ...: unable to record current working directory: Permission denied +sed 's/: unable to record current.*/: Permission denied/'outo1;mv o1 out + cmp out exp || fail=1 test $fail = 1 diff out exp 2 /dev/null ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: filutils 4.1
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 me. Thanks again for the comments. -- goesh On Thu, June 15, 2006 23:52, Jim Meyering wrote: [EMAIL PROTECTED] (Bob Proulx) wrote: goesh wrote: Further, i have used find . -print to do the same thing, however, i really like having the absoulte path in outputs such as ls -ltr, and i could not see a way to get find to do this. ... $ ls -ltrZ Well, I can't think of a way to have find sort by time. So it can't replace the ls -t behavior. But otherwise the following is similar. find $PWD/* -ls Hi Bob, You can make find print the mod-or-access time as an integer, along with the full file name, and then sort the result on time stamp: find $PWD/* -printf '%A@ %p\n'|sort -nr This email was sent from goesh.us. goesh.us ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: filutils 4.1
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 that needs to be updated to be struct timespec-aware. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: ia64 GNU/Linux pwd-long test failure in CVS coreutils
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 Jarno in http://sourceware.org/bugzilla/show_bug.cgi?id=2418. I dunno, though, that sounds like just masking the error. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: filutils 4.1
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 get it right. Looks like 'find' is another program that needs to be updated to be struct timespec-aware. I thought about this a year or so ago. The obvious thing to do is to change %A@ and friends so that they produce a number which is no longer an integer. I enquired on the bug-findutils mailing list about whether anybody thought that this would break scripts currently depending on the existing behaviour. At the time, I took no response as shrug rather than no. James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: ia64 GNU/Linux pwd-long test failure in CVS coreutils
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 than 4096 -- this is according to Aurelian Jarno in http://sourceware.org/bugzilla/show_bug.cgi?id=2418. I dunno, though, that sounds like just masking the error. I read that, too, but am not inclined to make the test program create such a deep hierarchy, just for ia64 (or whatever systems have PATH_MAX pagesize). Already, creating a hierarchy deep enough to trigger getcwd misbehavior is a little onerous. Quadrupling the depth/length seems excessive. However, if more systems end up being affected, or if someone can come up with a run-test that's not too unreasonable, then maybe it'd be worthwhile. FWIW, I think the proposed change would involve creating deeper and deeper directories, in spite of partially-failing getcwd calls, until the real failure (bug) when the length passes 16384. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
sleep args
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
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 typing to type line ccc all over again, and it might not even be left on my screen for me to copy. 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. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: sleep args
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. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: sleep args
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 it might be useful: 'sleep 1m -1s' could sleep 59 seconds rather than giving an error. -- Eric Blake ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [Chet Ramey] Re: current input line lost on ^Z
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 characters, before cat ever has a chance to see them. I don't know if you would have better success trying to track this down with xterm developers, or if it is a kernel issue, but coreutils is faithfully printing everything that is handed to it via read(). -- Eric Blake ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
