Re: su operation on RHES V5.2

2008-06-20 Thread Jim Meyering
Licause, Al [EMAIL PROTECTED] wrote:
 A few days ago, I sent an e-mail regarding the behaviour of
 su - usernameas seen in Redhat enterprise edition v5 update 2.

 Briefly if you su - username and that user name is an ldap user,
 no action appears to be taken.   The log shows the user was accessed
 then immediately disconnected.

 We have since found that if the nscd daemon is running, the su - username
 command works for ldap users. But as soon as nscd is stopped, the command
 again fails to take any action.

 We also reported that if su is run with strace, the command also succeeds.

 Can you tell us if this is expected behaviour ?

Thanks for the report.
However, upstream coreutils is phasing out support for su,
and in fact, with the latest version, coreutils-6.12, it
doesn't even install that program, by default.

Since strace appears not to be useful, the next step is usually
to run su via a debugger like gdb.


___
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 Jim Meyering
Poor Yorick [EMAIL PROTECTED] wrote:
 installing coreutils-6.12 on SunOS 5.9, with gcc-4.2.2 and gnu ld, Makefile
 contains unexpected \.1 entries in Makefile:

 MAN = uname.1
 chroot.1
...
Thanks for the report.

 for gl_i in `sed -n '/^'$v' =/,/[[^\]]$/p' $mk \
 | sed 's/^  *//;/^\$.*/d;/^'$v' =/d' \
 | tr -s '\\015\\012' '  '`; do
   gl_ADD_PROG([optional_bin_progs], $gl_i)
 done

 With solaris tr, the following command leaves the backslash in the output.
 It seems to have too many backslashes, and the number of spaces in the second
 argument of the tr command does not match the number of characters in the
 first argument:

 bash-2.05$ echo $'foo \\ \012 bar'  | tr -s '\\015\\012' '  '
 foo \
  bar

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.

 The following patch seems to work:
...
 -  | tr '\015\012' ' '; echo`
 +  | tr '\015\012' '  '; echo`

That is the part that was required.
Both tr-related problems were already fixed in git.

  http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=5f47278372
  http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=8253a9aeb4

You might want to try the latest snapshot next time,

  http://meyering.net/cu/coreutils-ss.tar.gz
  http://meyering.net/cu/coreutils-ss.tar.lzma


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


Re: really weird build problem on MacOSX/Tiger 10.4.11

2008-06-20 Thread Jim Meyering
 I'm attaching a shortened make warning showing a problem with ID vs
 id under the src subdir, along with an ls listing of that same
 subdir.  We're unable to get the final linked exe for id created
 there.  The HFS+ build volume is case sensitive, as is the boot

Thanks for the report.  However, ...

You are using a case-INsensitive file system.
Because of that, the default rule generated by automake
for ID (created by mkid) is conflicting with coreutils'
rule for id the program.

I suggest you build using a case sensitive file system.
...
 $ make -w
 make: Entering directory 
 `/Volumes/BigUn3/Projects/coreutils-6.12.29-a16be/src'
 Makefile:2050: warning: overriding commands for target `ID'
 Makefile:1569: warning: ignoring old commands for target `ID'


___
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


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: 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


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: 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. http://emr.cs.iit.edu/home/reingold/calendar-book/third-edition/.
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


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: 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 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: 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: 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: \.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


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