Jim Meyering <[EMAIL PROTECTED]> writes:
> it's because HP-UX's exec-family functions are not POSIX conforming.
Thanks for explaining this. The first failure, though, I think is
due to an unportable use of \< and \> in a sed pattern. And the
other failures can be worked around. I installed thi
The relevant file is libc/localedata/locales/en_US in glibc.
It contains bug-reporting info. But I suggest you read the
file first, and understand its reference to ISO/IEC 14651.
Your actual beef may be with that standard, and not with glibc.
___
Bug-c
Paul Eggert <[EMAIL PROTECTED]> wrote:
> Jim Meyering <[EMAIL PROTECTED]> writes:
>
>> it's because HP-UX's exec-family functions are not POSIX conforming.
>
> Thanks for explaining this. The first failure, though, I think is
> due to an unportable use of \< and \> in a sed pattern. And the
> oth
Works great, thank you for your assistance.
With Best Regards
Assaf Feuerstein
Unix System Administrator
Bezeq International
-Original Message-
From: Andreas Schwab [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 31, 2006 11:58 PM
To: Assaf Feuerstein
Cc: bug-coreutils@gnu.org
Subject:
Hi Paul,
* Paul Eggert wrote on Thu, Jun 01, 2006 at 09:14:42AM CEST:
> Jim Meyering <[EMAIL PROTECTED]> writes:
>
> > it's because HP-UX's exec-family functions are not POSIX conforming.
>
> Thanks for explaining this. The first failure, though, I think is
> due to an unportable use of \< and
$ date +%u%w
33
Shouldn't this be 43???
--
Rick Richardson [EMAIL PROTECTED]http://home.mn.rr.com/richardsons/
Linux printer driver for HP CLJ 2600n http://foo2hp.rkkda.com/
Linux printer driver (KM 2430 and HP 10xx) http://foo2zjs.rkkda.com/
Linux tools for geocaching
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Rick Richardson on 5/31/2006 9:55 PM:
> $ date +%u%w
> 33
>
> Shouldn't this be 43???
No. According to date --help, %u maps 1-7 starting at Monday, and %w maps
0-6 starting at Sunday. So one time in seven %u%w will be 70, all other
day
Ian Jackson <[EMAIL PROTECTED]> wrote:
> Package: coreutils
> Version: 5.2.1-2
>
> -davenant:~> strace -e trace=lstat64 /bin/ls --sort=none -i
> /export/mirror/Repository/data-md5 2>&1 | head
> lstat64("/export/mirror/Repository/data-md5/063096bcf34e489e5a6c3a7a20214368",
> {st_mode=S_IFREG|0664,
I wrote:
> Thanks for the report.
>
> You're right that in some cases ls could be optimized to avoid the
> lstat calls. However deciding when to do it is not easy.
> It is possible
> - when dirent.d_ino is available (this is easy), and
> - when dirent.d_ino is guaranteed to be valid (this is t
On 6/1/06, Jim Meyering <[EMAIL PROTECTED]> wrote:
> The latter is harder because for some files (mount points in a chroot
> with a buggy glibc) d_ino is nonzero and wrong. In those cases, you have
> to use lstat to get the true value. The invalid d_ino problem came up
> recently with the repo
Ralf Wildenhues <[EMAIL PROTECTED]> writes:
> Another way to provoke the runaway is to
> env TESTS='../../../coreutils-5.96/tests/misc/sort' make -e check
>
> but it doesn't happen with GNU make.
I can reproduce the problem even with GNU make (3.80).
My guess is that it's something about Sol
By analogy with other test scripts I found that the following patch
fixes the problem for me, but I don't know why (nor do I know why
$ENV{PROG} lines are in some test scripts but not all) so I haven't
installed this.
2006-06-01 Paul Eggert <[EMAIL PROTECTED]>
* tests/misc/sort: Set $EN
12 matches
Mail list logo
