coreutils-6.12.29-a16be - FAIL: misc/truncate-fail-diag.log

2008-06-20 Thread Poor Yorick 
Building latest snapshot of coreutils, coreutils-6.12.29-a16be, on SunOS 5.9,
with gcc-4.2.2 and gnu ld:

FAIL: misc/truncate-fail-diag.log

log attached.

-- 
Yorick



truncate-fail-diag.log
Description: Binary data
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: "\.1" entries in Makefile $MAN variable (Solaris 9)

2008-06-20 Thread Poor Yorick 
>  From: Jim Meyering <>
>  
>  That's not the same context as the above.
>  In the for loop above, the tr use is within a `...` context.
>  In *that* case, you'll find the extra backslashes are required.

Thank you for your reply.  I see what you mean about the extra backslashes.  I
tried again with snapshot you suggested (coreutils-6.12.29-a16be), and after
applying the following patch, it worked (with the exception of a failed test,
which I will report in another email):

--- configure.ac2008-06-20 16:19:14 -04:00
+++ configure.ac.new2008-06-20 21:58:10 -04:00
@@ -258,7 +258,7 @@
 v=EXTRA_PROGRAMS
 for gl_i in `sed -n '/^'$v' =/,/[[^\]]$/p' $mk \
 | sed 's/^  *//;/^\$.*/d;/^'$v' =/d' \
-| tr -s '\\015\\012' '  '`; do
+| tr -s '\\015\\012' '   '`; do
   gl_ADD_PROG([optional_bin_progs], $gl_i)
 done
 
@@ -313,7 +313,7 @@
 
 # Change ginstall.1 to "install.h" in $MAN.
 MAN=`for m in $MAN; do test $m = ginstall.1 && m=install.1; echo $m; done \
-  | tr '\015\012' ' '; echo`
+  | tr '\015\012' '  '; echo`
 
 # Remove [.1, since writing a portable rule for it in man/Makefile.am
 # is not practical.  The sed LHS below uses the autoconf quadrigraph

-- 
Yorick


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: check-AUTHORS fails because of non ansi characters

2008-06-20 Thread Eric Blake 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Jim Meyering on 6/20/2008 1:09 PM:
|> 58c58
|> < ptx: Fran?ois Pinard
|> ---
|>> ptx: François Pinard

In my email, this is rendering as one vs. two characters.  I suspect it
might be a locale issue - perhaps Jim is using a UTF-8 locale, and Michael
is using a Latin-1 encoding?  The proper_name_utf8 modules renders in
UTF-8, but then passes the result through iconv to transliterate into your
locale.

- --
Don't work too hard, make some time for fun as well!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkhcT1AACgkQ84KuGfSFAYCpOgCfcqJAEjS7LWiBk2GmWKQ+TNUH
26oAnAjARobxqWAv0R8yZXC4Wd/0WeTT
=OTK9
-END PGP SIGNATURE-


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Multi-threading in sort(or core-utils)

2008-06-20 Thread Paul Eggert 
Bo Borgerson <[EMAIL PROTECTED]> writes:

> Does this sound like a step in the right direction for sort?  If I were
> to clean this up and submit it would you be willing to assess its
> viability as a portable improvement?

Yes, and yes.  And thanks!


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: AIX 5.3 df coreutils reportes wrong size - 2.4T limit ?

2008-06-20 Thread Paul Eggert 
Jodok Ole Muellers <[EMAIL PROTECTED]> writes:

> AIX df:
> ===
> [EMAIL PROTECTED]:/# /bin/df -g /tsmstg:
> FilesystemGB blocks  Free %UsedIused %Iused Mounted on
> /dev/tsmstglv  18839.50  16384.47   14% 2515 1% /tsmstg
>
> coreutils df
> 
> [EMAIL PROTECTED]:/# /opt/freeware/bin/df -h /tsmstg
> FilesystemSize  Used Avail Use% Mounted on
> /dev/tsmstglv 2.4T  2.4T  485M 100% /tsmstg

If I had to guess, I'd guess that somebody is losing the high-order
bits of the amount of free space.  AIX df is reporting
20,228,759,093,248 bytes in the file system, which is 1265e000 in
hexadecimal.  the hexadecimal number 265e000 is equal to
2.3979... TiB, which GNU df would report as 2.4T.

It could be that the "somebody" is your AIX file system or kernel, or
it could be that the "somebody" is GNU df.  To find out, please fire
up a debugger and inspect the result of the statfs system call that
GNU "df" is issuing.  Or perhaps you can use the AIX equivalent of
Linux's strace to find out what statfs is doing.

If the statfs numbers are wrong, then the problem is in your kernel or
file system.  If the statfs numbers are right, then the problem is in
GNU df, and please let us know exactly what statfs returned.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: check-AUTHORS fails because of non ansi characters

2008-06-20 Thread Jim Meyering 
[EMAIL PROTECTED] (Michael Geng) wrote:
> when I'm doing make distcheck on the present git version it fails
> with the following message:
>
> ...
> diff authors-actual authors-dotdot && rm -f authors-actual authors-dotdot
> ...
> 58c58
> < ptx: Fran?ois Pinard
> ---
>> ptx: François Pinard
...
> It clearly has to do with non ansi characters in names. But what exactly
> is wrong?

Hi Michael,

That check expects --version output to contain names matching
exactly what's in the AUTHORS file.  This is accomplished
via proper_name_utf8:

#define AUTHORS proper_name_utf8 ("F. Pinard", "Fran\xc3\xa7ois Pinard")

So I suspect it's your system.
It's worked fine for me for weeks.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: AIX 5.3 df coreutils reportes wrong size - 2.4T limit ?

2008-06-20 Thread Jim Meyering 
Jodok Ole Muellers <[EMAIL PROTECTED]> wrote:
> Hello List,
>
> I just discovered that the df shipped with
> coreutils reports wrong size on AIX 5.3
>
> I tried with these packages:
> ftp://ftp.software.ibm.com/aix/freeSoftware/aixtoolbox/RPMS/ppc/coreutils/coreutils-5.2.1-2.aix5.1.ppc.rpm
> http://www.oss4aix.org/download/RPMS/coreutils/coreutils-6.11-1.aix5.1.ppc.rpm
>
>
> AIX df:
> ===
> [EMAIL PROTECTED]:/# /bin/df -g /tsmstg:
> FilesystemGB blocks  Free %UsedIused %Iused Mounted on
> /dev/tsmstglv  18839.50  16384.47   14% 2515 1% /tsmstg
>
> coreutils df
> 
> [EMAIL PROTECTED]:/# /opt/freeware/bin/df -h /tsmstg
> FilesystemSize  Used Avail Use% Mounted on
> /dev/tsmstglv 2.4T  2.4T  485M 100% /tsmstg
>
>
> The volume tsmstglv is 18TB but only 2.4T are reported.
> Furthermore df shows it as 100% full.
> I usually prefere GNU utils over AIX tools.

Thanks for the report.
This is the first I've heard of such a problem.
However, since the names suggest the binaries were
built for aix5.1, I wouldn't worry just yet.

Would you please try building from the latest sources?

  ftp://ftp.gnu.org/gnu/coreutils/coreutils-6.12.tar.lzma
  ftp://ftp.gnu.org/gnu/coreutils/coreutils-6.12.tar.gz

Or, even a recent snapshot, if you're feeling adventurous:

  http://meyering.net/cu/coreutils-ss.tar.gz8.7 MB
  http://meyering.net/cu/coreutils-ss.tar.lzma  3.6 MB


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Request for improving 'date' command

2008-06-20 Thread Paul Eggert 
Thanks for those contributions, but my understanding is that the
Persian calendar is astronomical, which means any numeric calculation
would be an approximation, right?  What approximation is being used
here?  Does the code work for dates arbitrarily in the past or future,
when time_t is 64 bits for example?  (I suspect the answer is "no".)
That sort of thing.

For more on this subject, please see Reingold & Dershowitz's excellent
book "Calendrical Calculations", 3rd
ed. .
It mentions multiple ways to approximate the Persian calendar, among
other things.

I suspect that modifying "date" to support the Persian calendar (much
less Hebrew, Hindu, Islamic, etc.) would be nontrivial, and would be
best done in a library that could be used by many programs, not just
"date".  You might want to look at Emacs's calendar code for ideas for
such a project, as the Emacs code was written by Reingold a while back
and is high quality.  (It's in Lisp, though.)


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

check-AUTHORS fails because of non ansi characters

2008-06-20 Thread Michael Geng 
Hi,

when I'm doing make distcheck on the present git version it fails
with the following message:

...
diff authors-actual authors-dotdot && rm -f authors-actual authors-dotdot
...
58c58
< ptx: Fran?ois Pinard
---
> ptx: François Pinard
...
make[3]: *** [check-AUTHORS] Error 1
...

It clearly has to do with non ansi characters in names. But what exactly 
is wrong?

Does AUTHORS now have to be updated? Or do the source files (ptx.c in this 
case) have to be updated? Or is there anything wrong with my Linux 
installation?

Michael


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: BUG: md5sum 5.97

2008-06-20 Thread Eric Blake 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Sam Liddicott on 6/20/2008 5:03 AM:
| Try running md5sum 5.97

Consider upgrading - the latest stable version of coreutils is 6.12, with
a number of bug fixes in the meantime.

| on a file with \ in it's name; and the output is
| prefixed with a \

This is intentional, and in newer versions of coreutils, the documentation
was even updated to mention this.  GNU *sum utilities add escape sequences
into file names to allow for unambiguous parsing of those file names, even
if they contain newlines or backslashes.  (Still not fixed, but on my TODO
list, is to write a patch to extend this escaping process to also cover \r
characters in filenames, to make *sum robust to checksum lists that have
been accidentally converted to CRLF line endings).

- --
Don't work too hard, make some time for fun as well!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkhbn+4ACgkQ84KuGfSFAYAWPwCghq8lYx1G89GBDbxwwRREtZrT
N/cAnR7A6qBPghX6WQV9uJ5MVMjonjVO
=7Nms
-END PGP SIGNATURE-


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

BUG: md5sum 5.97

2008-06-20 Thread Sam Liddicott 
Try running md5sum 5.97 on a file with \ in it's name; and the output is
prefixed with a \

e.g.

$ echo hello > file\\name
$ md5sum file\\name
\b1946ac92492d2347c6235b4d2611184  file\\name
$ md5sum < file\\name
b1946ac92492d2347c6235b4d2611184  -

Sam


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

AIX 5.3 df coreutils reportes wrong size - 2.4T limit ?

2008-06-20 Thread Jodok Ole Muellers 
Hello List,

I just discovered that the df shipped with 
coreutils reports wrong size on AIX 5.3

I tried with these packages:
ftp://ftp.software.ibm.com/aix/freeSoftware/aixtoolbox/RPMS/ppc/coreutils/coreutils-5.2.1-2.aix5.1.ppc.rpm
http://www.oss4aix.org/download/RPMS/coreutils/coreutils-6.11-1.aix5.1.ppc.rpm


AIX df:
===
[EMAIL PROTECTED]:/# /bin/df -g /tsmstg:
FilesystemGB blocks  Free %UsedIused %Iused Mounted on
/dev/tsmstglv  18839.50  16384.47   14% 2515 1% /tsmstg

coreutils df

[EMAIL PROTECTED]:/# /opt/freeware/bin/df -h /tsmstg
FilesystemSize  Used Avail Use% Mounted on
/dev/tsmstglv 2.4T  2.4T  485M 100% /tsmstg


The volume tsmstglv is 18TB but only 2.4T are reported.
Furthermore df shows it as 100% full.
I usually prefere GNU utils over AIX tools.

Is this a know problem with a 2.4T limit
or has this something to do with 32bit vs 64bit ?

Any help is much appreciated.


Best regards
Jodok Ole Müllers

-- 
Mit freundlichen Grüßen
Jodok Ole Müllers

Aschendorff Medien GmbH & Co. KG
An der Hansalinie 1
48163 Münster
Telefon : (0251) 690-9474
Telefax : (0251) 690-902
Email   : mailto:[EMAIL PROTECTED]
Website : http://www.aschendorff.de


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: sort --batch-size non-merge bug

2008-06-20 Thread Jim Meyering 
Bo Borgerson <[EMAIL PROTECTED]> wrote:
> If --batch-size is used with a non-merge sort (to govern the merge of
> temp files), and there is no --buffer-size set in conjunction, then the
> minimum SORT_SIZE will be enforced resulting in severe performance
> degradation.
>
> I've attached a fix for this bug, including a test that exercises it.
> I've also pushed to repo.or.cz.

Thanks for catching that.

Applied and pushed.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils