Re: 5.96: chgrp/basic failure on OpenBSD

[Paul Eggert]

Ralf Wildenhues <[EMAIL PROTECTED]> writes:

> With 5.96, I get one test failure on i386-unknown-openbsd3.8.

Possibly you're suffering from this problem, noted in tests/chgrp/basic:

  # The following no-change chgrp command is supposed to update f's ctime,
  # but on OpenBSD, it appears to be a no-op for some file system types
  # (at least NFS) so g's ctime is more recent.  This is not a big deal;
  # this test works fine when the files are on a local file system (/tmp).

For what it's worth, I couldn't reproduce your problem on OpenBSD 3.4
x86.  I tried with the coreutils source on an NFS directory (exported
from Solaris 8) and on a local directory.

However, the problem has been reported on MacOS X hosts, e.g.:

http://lists.gnu.org/archive/html/bug-coreutils/2006-05/msg00056.html
http://lists.gnu.org/archive/html/bug-coreutils/2005-10/msg5.html

This problem comes up often enough (i.e., buggy operating systems)
that perhaps we should simply disable the test?


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

Re: 5.96: chgrp/basic failure on OpenBSD

[Ralf Wildenhues]

Hi Paul,

* Paul Eggert wrote on Mon, May 29, 2006 at 09:54:04AM CEST:
> Ralf Wildenhues <[EMAIL PROTECTED]> writes:
> 
> > With 5.96, I get one test failure on i386-unknown-openbsd3.8.
> 
> Possibly you're suffering from this problem, noted in tests/chgrp/basic:
> 
>   # The following no-change chgrp command is supposed to update f's ctime,
>   # but on OpenBSD, it appears to be a no-op for some file system types
>   # (at least NFS) so g's ctime is more recent.  This is not a big deal;
>   # this test works fine when the files are on a local file system (/tmp).

FWIW, this happened on a local file system though (ffs), no NFS involved.

Cheers,
Ralf


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

Re: AIX grep limitation: coreutils build failure

[Paul Eggert]

Ralf Wildenhues <[EMAIL PROTECTED]> writes:

> I don't mind the plug, but unfortunately, things are not so simple:
> The `grep -c' apparently keeps going, and just omits counting the line
> that was too long (as it happens, the LTLIBOBJS and the LIBOBJS
> substitutions are in different conf$$subs.sed files).  This means we
> both get a whole slew of errors

OK, thanks, how about this fix instead?

(My reluctance to use tr is due to the fact that we don't rely on it
now, so why add it)

* lib/autoconf/status.m4 (_AC_OUTPUT_FILES_PREPARE):
Don't assume 'grep' works on long lines, since AIX grep doesn't.

--- status.m4.~1.110.~  2006-05-27 14:52:20.0 -0700
+++ status.m4   2006-05-29 02:18:10.0 -0700
@@ -401,7 +401,8 @@ m4_if(_AC_SED_CMD_LIMIT,
   m4_if(_AC_Var, [EMAIL PROTECTED]@], m4_if(_AC_SED_CMD_NUM, 2, 2, 
_AC_SED_CMD_LIMIT), _AC_SED_CMD_NUM),
 [_ACEOF
 
-  if test `grep -c "$ac_delim\$" conf$$subs.sed` = _AC_SED_DELIM_NUM; then
+dnl Do not use grep on conf$$subs.sed, since AIX grep has a line length limit.
+  if test `sed -n "s/.*$ac_delim\$/X/p" conf$$subs.sed | grep -c X` = 
_AC_SED_DELIM_NUM; then
 break
   elif $ac_last_try; then
 AC_MSG_ERROR([could not make $CONFIG_STATUS])
@@ -410,10 +411,11 @@ m4_if(_AC_SED_CMD_LIMIT,
   fi
 done
 
-ac_eof=
-if grep '^CEOF$' conf$$subs.sed >/dev/null; then
-  ac_eof=`sed -n '/^CEOF[[0-9]]*$/s/CEOF//p' conf$$subs.sed | sort -nru | sed 
1q`
-  ac_eof=`expr 0$ac_eof + 1`
+dnl Similarly, avoid grep here too.
+ac_eof=`sed -n '/^CEOF[[0-9]]*$/s/CEOF/0/p' conf$$subs.sed`
+if test -n "$ac_eof"; then
+  ac_eof=`echo "$ac_eof" | sort -nru | sed 1q`
+  ac_eof=`expr $ac_eof + 1`
 fi
 
 dnl Increment fragment number.


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

Re: Missing variable quoting in m4 files

[Roland Illig]

Jim Meyering wrote:

Paul Eggert <[EMAIL PROTECTED]> wrote:
...


That patch masks the actual error, which is that the variable was used
without being defined.  The underlying bug was fixed in a different
way, as described in
.

I assume you're talking about coreutils 5.95.

Jim, perhaps this fix should also be propagated into the b5_9x branch?
(I just now propagated it into Autoconf CVS.)



Thanks.
That fix made it onto the branch just in time for 5.96.


Thanks for fixing the bug.

Roland


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

Question about md5sum

[Arseny Solokha]

Hello!
I have a question about md5sum 5.2.1.
For example, I'm in deirectory /home/arseny and I want to get hash of
file foo.bar. I have to write md5sum /home/arseny/foo.bar. But I
consider that it would be more natural to look file firstly in current
directory. For example command would be
cd /home/arseny
md5sum foo.bar
I'm beginner in Linux but I consider that my vision to this is more
convinient and natural.
Best regards,
Arseny.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Question about md5sum

[Arseny Solokha]

Hello!
I have a question about md5sum 5.2.1.
For example, I'm in deirectory /home/arseny and I want to get hash of
file foo.bar. I have to write md5sum /home/arseny/foo.bar. But I
consider that it would be more natural to look file firstly in current
directory. For example command would be
cd /home/arseny
md5sum foo.bar
I'm beginner in Linux but I consider that my vision to this is more
convinient and natural.
Best regards,
Arseny.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Question about md5sum

[Eric Blake]

> I have a question about md5sum 5.2.1.

5.2.1 is several years old; I would consider upgrading.  The latest
stable version is 5.96, and a 5.97 will probably arrive within the next
month or so.

> For example, I'm in deirectory /home/arseny and I want to get hash of
> file foo.bar. I have to write md5sum /home/arseny/foo.bar. But I
> consider that it would be more natural to look file firstly in current
> directory. For example command would be
> cd /home/arseny
> md5sum foo.bar

That command works just fine for me.  I don't know why you
are having problems with it, but what you describe is already
possible with md5sum.

-- 
Eric Blake


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

Re: OSF/4.0D strtold

[Albert Chin]

On Sat, May 27, 2006 at 09:47:28PM +0200, Ralf Wildenhues wrote:
> Tru64 UNIX 4.0D doesn't provide strtold (in the standard library at
> least), but /usr/include.dtk/stdlib.h provides a declaration.  Thus the
> compile test in c-strtod.m4 fails.  This causes a link failure for
> coreutils-5.96 printf.  The patch below seems to fix this (but I don't
> know whether it should rather be searched for in some library).

You can also fix it by building with -std1 but I don't know if this
will cause other problems. The commercial Tru64 UNIX compiler has
functions declared in /usr/include.dtk but not available in the shared
library.

-- 
albert chin ([EMAIL PROTECTED])


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

5.96: 3 test failures on HP-UX 11.23

[Ralf Wildenhues]

I get 3 failures on hppa2.0w-hp-hpux11.23:
misc/close-stdout, touch/no-create-missing, and help-version (groups),
see the verbose output below.  Note that I also get the warning below.

On ia64-hp-hpux11.23, the same tests fail.
On hppa2.0w-hp-hpux11.11, I get no test failures, and no such warning.

Cheers,
Ralf


WARNING: On this system, the built-in echo function of /bin/sh
does not report failure when writing to a full device.
To demonstrate, run this command:

  /bin/sh -c 'echo hello > /dev/full; echo status=$?'

Notice that the failing echo leaves its exit status set to zero
and does not produce a diagnostic.

That bug in /bin/sh would cause the test of the groups
scripts to fail, so it is being removed from the list of
programs checked by this test.



gmake  check-TESTS
gmake[1]: Entering directory 
`/home/ralf/coreutils/build-hppa2.0w-hp-hpux11.23/tests/misc'
+ rm --version
rm (GNU coreutils) 5.96
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software.  You may redistribute copies of it under the terms of
the GNU General Public License .
There is NO WARRANTY, to the extent permitted by law.

Written by Paul Rubin, David MacKenzie, Richard Stallman, and Jim Meyering.
+ + pwd
pwd=/home/ralf/coreutils/build-hppa2.0w-hp-hpux11.23/tests/misc
+ + echo ../../../coreutils-5.96/tests/misc/close-stdout
+ sed s,.*/,,
t0=close-stdout.tmp
+ tmp=close-stdout.tmp/17850
+ trap status=$?; cd $pwd; chmod -R u+rwx $t0; rm -rf $t0 && exit $status 0
+ trap (exit $?); exit $? 1 2 13 15
+ framework_failure=0
+ mkdir -p close-stdout.tmp/17850
+ cd close-stdout.tmp/17850
+ test 0 = 1
+ 
PATH=/home/ralf/coreutils/build-hppa2.0w-hp-hpux11.23/tests/misc/../..:/home/ralf/coreutils/build-hppa2.0w-hp-hpux11.23/tests/misc/../../src:/home/ralf/bin:/bin:/usr/bin:/sbin:/usr/sbin:/usr/bin/X11:/opt/aCC/bin:/opt/ansic/bin:/usr/ccs/bin:/usr/contrib/bin/X11
+ export PATH
+ fail=0
+ touch a
+ cp a b
+ + test -f b
+ chmod o-w .
+ + ln a c
+ + rm c
+ + mkdir d
+ + mv d e
+ + rmdir e
+ + touch e
+ + sleep 0
+ + /home/ralf/coreutils/build-hppa2.0w-hp-hpux11.23/tests/misc/../../src/true
+ + /home/ralf/coreutils/build-hppa2.0w-hp-hpux11.23/tests/misc/../../src/printf
+ + 
/home/ralf/coreutils/build-hppa2.0w-hp-hpux11.23/tests/misc/../../src/printf foo
+ 2> /dev/null
+ fail=1
+ cp --verbose a b
+ 2> /dev/null
+ fail=1
+ exit 1
+ exit 1
+ status=1
+ cd /home/ralf/coreutils/build-hppa2.0w-hp-hpux11.23/tests/misc
+ chmod -R u+rwx close-stdout.tmp
+ rm -rf close-stdout.tmp
+ exit 1
FAIL: close-stdout

gmake  check-TESTS
gmake[1]: Entering directory 
`/home/ralf/coreutils/build-hppa2.0w-hp-hpux11.23/tests/touch'
+ touch --version
touch (GNU coreutils) 5.96
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software.  You may redistribute copies of it under the terms of
the GNU General Public License .
There is NO WARRANTY, to the extent permitted by law.

Written by Paul Rubin, Arnold Robbins, Jim Kingdon, David MacKenzie, and Randy 
Smith.
+ + pwd
pwd=/home/ralf/coreutils/build-hppa2.0w-hp-hpux11.23/tests/touch
+ + echo ../../../coreutils-5.96/tests/touch/no-create-missing
+ sed s,.*/,,
tmp=no-create-missing.tmp
+ trap status=$?; cd $pwd; rm -rf $tmp && exit $status 0
+ trap (exit $?); exit 1 2 13 15
+ framework_failure=0
+ mkdir no-create-missing.tmp
+ cd no-create-missing.tmp
+ test 0 = 1
+ fail=0
+ touch -c no-file
+ 1> /dev/null 2>& 1
+ touch -cm no-file
+ 1> /dev/null 2>& 1
+ touch -ca no-file
+ 1> /dev/null 2>& 1
+ touch -c -
+ 2> /dev/null
+ fail=1
+ touch -cm -
+ 2> /dev/null
+ fail=1
+ touch -ca -
+ 2> /dev/null
+ fail=1
+ exit 1
+ exit 1
+ status=1
+ cd /home/ralf/coreutils/build-hppa2.0w-hp-hpux11.23/tests/touch
+ rm -rf no-create-missing.tmp
+ exit 1
FAIL: no-create-missing



$ gmake check-TESTS VERBOSE=yes TESTS=help-version
[...]

+ test groups = test
+ test groups = false
+ test groups = install
+ ../src/groups --help
+ 1> h-groups
+ ../src/groups --version
+ 1> /dev/null
+ grep bug-coreutils@gnu.org h-groups
+ 1> /dev/null
+ rm -f h-groups
+ test -w /dev/full
+ test -c /dev/full
+ ../src/groups --help
+ 1> /dev/full 2> /dev/null
+ fail=1
+ ../src/groups --version
+ 1> /dev/full 2> /dev/null
+ fail=1
+ status=0
+ test groups = [
+ prog=groups
+ eval expected=$expected_failure_status_groups
+ expected=
+ test x = x
+ expected=1
+ test 0 = 1
+ fail=1
+ echo *** groups: bad exit status `0' (expected 1),
+ 1>& 2
*** groups: bad exit status `0' (expected 1),
+ echo   with --help or --version output redirected to /dev/full
+ 1>& 2
  with --help or --version output redirected to /dev/full
+ test head = test
+ test head = false
+ test head = install
[...]

[ three instances of the above sequence ]

+ 0< in-17911 1> out-17911
+ :
+ rm -rf in-17911 in2-17911 out-17911 dir-17911
+ cd ..
+ rm -rf tmp-17911
+ exit 1
FAIL: help-version


___

Re: AIX grep limitation: coreutils build failure

[Ralf Wildenhues]

Hi Paul,

* Paul Eggert wrote on Mon, May 29, 2006 at 11:19:31AM CEST:
> 
> OK, thanks, how about this fix instead?

This is fine with me, thank you.

> (My reluctance to use tr is due to the fact that we don't rely on it
> now, so why add it)

Fine with me, too.  Please note though that tr is used in
lib/autotest/general.m4 and lib/autoconf/status.m4 already.

To cope with limited grep, coreutils is still missing the Automake
patch.  I guess you could also choose to ignore this, as both of these
failures happen on AIX <= 5.1.  Advising people to
  --disable-dependency-tracking

there helps get around the missing Automake patch, too (but not the
patch we're currently discussing).

We still don't know what that Solaris failure was about, though, I
guess.  Which is one reason I think this change may still be quite
valuable.

Cheers,
Ralf

>   * lib/autoconf/status.m4 (_AC_OUTPUT_FILES_PREPARE):
>   Don't assume 'grep' works on long lines, since AIX grep doesn't.


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

Re: AIX tests failures

[Albert Chin]

On Sun, May 28, 2006 at 05:52:45PM +0200, Ralf Wildenhues wrote:
> And yes, that happens with GCC as well.  They simply forget the final
> `\0', I guess.  As also mentioned here[2], the strndup declaration is
> #ifdef'ed away behind a _LINUX_SOURCE_COMPAT define.
> 
> I guess Autoconf should have a AC_FUNC_STRNLEN analogous to
> AC_FUNC_STRNLEN, and the Gnulib strnlen modules should use that.
> I don't know whether other buggy strn* functions exist on AIX.

When we build coreutils on AIX 4, we add the following to ./configure:
  ac_cv_func_strndup=no ac_cv_have_decl_strndup=no

The -D_LINUX_SOURCE_COMPAT was added to a future AIX 4.3.3 release by
a libc patch so we ignore to avoid customers having to upgrade their
libc.

-- 
albert chin ([EMAIL PROTECTED])


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

Re: AIX tests failures

[Albert Chin]

On Sun, May 28, 2006 at 07:58:24PM +0200, Jim Meyering wrote:
> I have to confess that I wonder if it's worth trying to work around
> bugs in AIX 4.  Is it still officially supported?  Is it used by many?
> I haven't had access to such a system for a few years now, and no one
> has been building coreutils on any version of AIX, as far as I've heard.
> But since it affects 5.1, too, maybe it's worthwhile.

We reported a problem with shred from coreutils-5.2.1 on AIX 5.2 on
May 13, 2004:
  http://lists.gnu.org/archive/html/bug-gnu-utils/2004-05/msg00028.html

We're definitely building coreutils on AIX 4.3.3, 5.1, 5.2, and 5.3
and have customers relying on it.

-- 
albert chin ([EMAIL PROTECTED])


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

Re: Support bytesize comparison in sort

[Mart Somermaa]

What is the general consensus on adding the '--human-readable-bytesize'
otpion to sort? The initial response seemed positive and I personally
crave for the feature for 'du -hs | sort -h'.



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

Re: coreutils-5.96 doesn't build (out of the box)

[Sam Sirlin]

   Date: Sun, 28 May 2006 10:55:23 +0200
   From: Ralf Wildenhues <[EMAIL PROTECTED]>

   * Sam Sirlin wrote on Sun, May 28, 2006 at 01:20:04AM CEST:
   > 
   > Here's the full output of the bad configure (autoconf 2.59 produced a
   > working configure)

   I still have no idea what's going on in your case (and I guess the bug
   you observe is different from the one on AIX).  So I have a few further
   questions.

   What is
 /bin/bash --version
 echo $PATH
 type mkdir expr dirname basename

dirname is apparently the issue. I had an old dirname shell script
lying around from 1989 in my path (version 1.5). It worked well enough
for the old  2.59 configure, but not for the new one which seems to
use a new construction "dirname -- ..."

I moved away the shell script, so now gnu dirname is available, and
then the new configure works fine, and 5.96 builds, even passes most
tests. 

FAIL: symlink-slash

==
1 of 21 tests failed
(3 tests were not run)


Sorry to bother you with a local environment problem. 
Thanks for the help,

Sam Sirlin
Email: [EMAIL PROTECTED]



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

Re: coreutils-5.96 doesn't build (out of the box)

[Ralf Wildenhues]

* Sam Sirlin wrote on Mon, May 29, 2006 at 10:41:03PM CEST:
>From: Ralf Wildenhues <[EMAIL PROTECTED]>

>  /bin/bash --version
>  echo $PATH
>  type mkdir expr dirname basename
> 
> dirname is apparently the issue. I had an old dirname shell script
> lying around from 1989 in my path (version 1.5). It worked well enough
> for the old  2.59 configure, but not for the new one which seems to
> use a new construction "dirname -- ..."

Is your script home-grown or does it have some wider usage?  What does
it output upon
  dirname -- /

?  I'm asking because maybe we can easily rule that out as non-working,
maybe even just by
   if (as_d=`dirname -- /` && test "$as_d" = /) >/dev/null 2>&1; then
 echo good
   else
 echo bad
   fi

Cheers, and thanks for checking,
Ralf


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

Re: Bug#369468: coreutils: ls.1 implies that -v is not a sort option

[Jim Meyering]

Justin Pryzby <[EMAIL PROTECTED]> wrote:
> Package: coreutils
> Version: 5.94-1
> Severity: minor
> Tags: upstream patch
> X-Fuzzies-Translation: yes
>
> :.!man ls |grep -i sort
> Reformatting ls(1), please wait...
>Sort entries alphabetically if none of -cftuSUX nor --sort.
>^^^
> [...]
>
>-v sort by version
>   
>
> --- ls.c  2006-01-21 05:51:16.0 -0500
> +++ /tmp/ls.c 2006-05-28 17:52:35.0 -0400
> @@ -4100,7 +4100,7 @@
>printf (_("Usage: %s [OPTION]... [FILE]...\n"), program_name);
>fputs (_("\
>  List information about the FILEs (the current directory by default).\n\
> -Sort entries alphabetically if none of -cftuSUX nor --sort.\n\
> +Sort entries alphabetically if none of -cftuvSUX nor --sort.\n\
>  \n\
>  "), stdout);
>fputs (_("\

Thanks.
Applied upstream.


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