Re: sort: memory exhausted with 50GB file
Paul Eggert [EMAIL PROTECTED] wrote: ... Hmm, it sounds like your input data has some very long lines, then. That would explain at least part of your problem, then. 'sort' needs to keep at least two lines in main memory to compare them: if single input lines are many gigabytes long, then 'sort' must consume many gigabytes of memory, regardless of what parameter you specify with '-S'. You can run this to find the maximum line length: wc --max-line-length your-data ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: signbit glitch (coreutils 6.10, Solaris 8 sparc, GCC 4.2.2)
Bruno Haible [EMAIL PROTECTED] writes: The warning goes away if one uses __builtin_signbit instead of signbit. Yes, thanks, I tested that patch on Solaris 8 and it does fix the warning. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] Add jfbterm to the dircolors TERM list
Mike Frysinger [EMAIL PROTECTED] wrote: diff --git a/src/dircolors.hin b/src/dircolors.hin index 838fa8f..3fb5a2f 100644 --- a/src/dircolors.hin +++ b/src/dircolors.hin @@ -30,6 +30,7 @@ TERM dtterm TERM eterm-color TERM gnome TERM gnome-256color +TERM jfbterm TERM konsole TERM kterm TERM linux Thanks. Applied. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[bug #22121] chcon help output refers to lchown system call
Update of bug #22121 (project coreutils): Status:None = Invalid Open/Closed:Open = Closed ___ Follow-up Comment #1: Thanks for the report, but that doesn't affect GNU coreutils: $ chcon --help|grep -A1 -e -h, -h, --no-dereference affect symbolic links instead of any referenced file (available only on systems with lchown system call) You must be looking at a version based on Red Hat's old patch. That has been superseded by what's upstream. But since coreutils-6.10 is so new (this is the first stable release with the revamped SELinux support) you may have to wait a while for it to get into the distribution of your choice. ___ Reply to this item at: http://savannah.gnu.org/bugs/?22121 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: new snapshot [Re: coreutils 6.9.92 fail to configure on *bsd
On Sat, Jan 26, 2008 at 08:58:34AM +0100, Jim Meyering wrote: Please do this as root: cd coreutils-6.10/src ./id -a ./rm -rf f g echo a f ./chown +0:+0 f ls -ld . f ./cp f g ls -l g and look at the output. The final ls should show g with group root. For some reason it doesn't. # cd coreutils-6.10/src # ./id -a uid=0(root) gid=0(wheel) groups=0(wheel),1(daemon),8(procview), 2(kmem),29(certusers),3(sys),9(procmod),4(tty), 102(com.apple.sharepoint.group.2),5(operator),80(admin),20(staff), 101(com.apple.sharepoint.group.1) # ./rm -rf f g # echo a f # ./chown +0:+0 f # ls -ld . f drwxr-xr-x 3 pipping staff 11186 Jan 26 12:29 . -rw-r--r-- 1 root wheel 2 Jan 26 12:29 f # ./cp f g # ls -l g -rw-r--r-- 1 root staff 2 Jan 26 12:29 g # ( exactly the same happens when the bsd tools in /usr/bin and /bin are used instead btw ) If not, please repeat but with this in place of the ./cp command above: strace -o log ./cp f g and then send the output as well as the contents of log to the list. Sorry, but there's no strace on darwin9. -- Elias pgpKTuCR23QqD.pgp Description: PGP signature ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: new snapshot [Re: coreutils 6.9.92 fail to configure on *bsd
Elias Pipping [EMAIL PROTECTED] wrote: On Sat, Jan 26, 2008 at 08:58:34AM +0100, Jim Meyering wrote: Please do this as root: cd coreutils-6.10/src ./id -a ./rm -rf f g echo a f ./chown +0:+0 f ls -ld . f ./cp f g ls -l g and look at the output. The final ls should show g with group root. For some reason it doesn't. # cd coreutils-6.10/src # ./id -a uid=0(root) gid=0(wheel) groups=0(wheel),1(daemon),8(procview), 2(kmem),29(certusers),3(sys),9(procmod),4(tty), 102(com.apple.sharepoint.group.2),5(operator),80(admin),20(staff), 101(com.apple.sharepoint.group.1) # ./rm -rf f g # echo a f # ./chown +0:+0 f # ls -ld . f drwxr-xr-x 3 pipping staff 11186 Jan 26 12:29 . -rw-r--r-- 1 root wheel 2 Jan 26 12:29 f # ./cp f g # ls -l g -rw-r--r-- 1 root staff 2 Jan 26 12:29 g That suggests that the bogus group is set by cp's open call. I suspect some sort of ACL mechanism that specifies staff as the default group -- or maybe some rule says inherit group from parent directory. Do you see the same behavior if you run those commands in /tmp? (in place of ./, you'll need /abs/path-to/coreutils-6.10/src/) ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: new snapshot [Re: coreutils 6.9.92 fail to configure on *bsd
On Sat, Jan 26, 2008 at 02:19:12PM +0100, Andreas Schwab wrote: Elias Pipping [EMAIL PROTECTED] writes: Sorry, but there's no strace on darwin9. The darwin equivalent appears to be ktrace. Indeed. While ktrace came with darwin8, it no longer comes with darwin9, though. -- Elias pgpur5peCqHZx.pgp Description: PGP signature ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: new snapshot [Re: coreutils 6.9.92 fail to configure on *bsd
On Sat, Jan 26, 2008 at 01:54:58PM +0100, Jim Meyering wrote: Elias Pipping [EMAIL PROTECTED] wrote: # ls -ld . f drwxr-xr-x 3 pipping staff 11186 Jan 26 12:29 . -rw-r--r-- 1 root wheel 2 Jan 26 12:29 f # ./cp f g # ls -l g -rw-r--r-- 1 root staff 2 Jan 26 12:29 g That suggests that the bogus group is set by cp's open call. I suspect some sort of ACL mechanism that specifies staff as the default group -- or maybe some rule says inherit group from parent directory. The latter seems to be the case. Do you see the same behavior if you run those commands in /tmp? (in place of ./, you'll need /abs/path-to/coreutils-6.10/src/) # pwd /tmp # /Users/pipping/coreutils-6.10/src/id -a uid=0(root) gid=0(wheel) groups=0(wheel),1(daemon),8(procview), 2(kmem),29(certusers),3(sys),9(procmod),4(tty), 102(com.apple.sharepoint.group.2),5(operator),80(admin),20(staff), 101(com.apple.sharepoint.group.1) # /Users/pipping/coreutils-6.10/src/rm -rf f g # echo a f # /Users/pipping/coreutils-6.10/src/chown +0:+0 f # ls -ld . f drwxrwxrwt 9 root wheel 374 Jan 26 15:10 . -rw-r--r-- 1 root wheel2 Jan 26 15:10 f # /Users/pipping/coreutils-6.10/src/cp f g # ls -l g -rw-r--r-- 1 root wheel 2 Jan 26 15:11 g # -- Elias pgp68V1XRsGXv.pgp Description: PGP signature ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: new snapshot [Re: coreutils 6.9.92 fail to configure on *bsd
Elias Pipping [EMAIL PROTECTED] wrote: On Sat, Jan 26, 2008 at 01:54:58PM +0100, Jim Meyering wrote: Elias Pipping [EMAIL PROTECTED] wrote: # ls -ld . f drwxr-xr-x 3 pipping staff 11186 Jan 26 12:29 . -rw-r--r-- 1 root wheel 2 Jan 26 12:29 f # ./cp f g # ls -l g -rw-r--r-- 1 root staff 2 Jan 26 12:29 g That suggests that the bogus group is set by cp's open call. I suspect some sort of ACL mechanism that specifies staff as the default group -- or maybe some rule says inherit group from parent directory. The latter seems to be the case. It does, indeed. Please see if this makes the test pass: Avoid cp/preserve-gid test failure on Mac OS 10.5.1 (Darwin 9.1) * tests/cp/preserve-gid: Set group as well as owner on .. Reported by Elias Pipping. diff --git a/tests/cp/preserve-gid b/tests/cp/preserve-gid index 5f2c050..9537dc0 100755 --- a/tests/cp/preserve-gid +++ b/tests/cp/preserve-gid @@ -1,7 +1,7 @@ #!/bin/sh # Verify that cp -p preserves GID when it is possible. -# Copyright (C) 2007 Free Software Foundation, Inc. +# Copyright (C) 2007, 2008 Free Software Foundation, Inc. # This program is free software: you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by @@ -61,7 +61,7 @@ if test -z $nameless_uid \ skip_test_ couldn't find a nameless UID or GID fi -chown +$nameless_uid . +chown +$nameless_uid:+0 . create a0 0 0 create b0 $nameless_uid $nameless_gid1 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: isnanl problem on Solaris 8 with GCC 4.2.2
Paul Eggert wrote: I ran into this problem when compiling coreutils 6.10 on Solaris 8 (sparc) with GCC 4.2.2: frexp.c: In function 'rpl_frexpl': frexp.c:63: warning: implicit declaration of function 'isnanl' vasnprintf.c: In function 'is_infinitel': vasnprintf.c:252: warning: implicit declaration of function 'isnanl' Here, the problem is that isnanl is defined by libm, but it's not declared anywhere in /usr/include. If that was the problem, one would also see the warning when gcc-3.x is used. And I can see with nm that libm on Solaris 8 does not have 'isnanl'. The problem is that GCC knows about isnanl as a built-in function. It is compiled like __builtin_isnanl (supported by GCC = 4.0), but gives a warning. Here's a patch: 2008-01-24 Paul Eggert [EMAIL PROTECTED] * m4/isnanl.m4: Check that isnanl is declared, when it's used. (gl_HAVE_ISNANL_NO_LIBM, gl_HAVE_ISNANL_IN_LIBM): Check that isnanl is declared, if we are not going to override it anyway. This suppresses a warning when compiling coreutils 6.10 with GCC 4.2.2 on Solaris 8. In that combination, no include file defines isnanl, but it's in libm, and GCC issues a warning when compiling. Although your patch is correct, I prefer not to use it: It has the effect to reject GCC's built-in. Instead I find it better to use this built-in (on those platforms where it works), since that will save a function call. GCC's built-in does not pass our tests on x86, x86_64, ia64. But the libc function does not do either. So it's acceptable to prefer the GCC built-in to the libc implementation always. Committed this: 2008-01-26 Bruno Haible [EMAIL PROTECTED] * m4/isnanl.m4 (gl_HAVE_ISNANL_NO_LIBM, gl_HAVE_ISNANL_IN_LIBM, gl_FUNC_ISNANL_WORKS): Test the GCC = 4.0 built-in. * lib/isnanl.h (isnanl): Use the GCC = 4.0 built-in. * lib/isnanl-nolibm.h (isnanl): Likewise. Reported by Paul Eggert [EMAIL PROTECTED]. *** lib/isnanl-nolibm.h.orig2008-01-26 15:41:57.0 +0100 --- lib/isnanl-nolibm.h 2008-01-26 15:39:22.0 +0100 *** *** 1,5 /* Test for NaN that does not need libm. !Copyright (C) 2007 Free Software Foundation, Inc. This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by --- 1,5 /* Test for NaN that does not need libm. !Copyright (C) 2007-2008 Free Software Foundation, Inc. This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by *** *** 17,23 #if HAVE_ISNANL_IN_LIBC /* Get declaration of isnan macro or (older) isnanl function. */ # include math.h ! # ifdef isnan # undef isnanl # define isnanl(x) isnan ((long double)(x)) # endif --- 17,27 #if HAVE_ISNANL_IN_LIBC /* Get declaration of isnan macro or (older) isnanl function. */ # include math.h ! # if __GNUC__ = 4 !/* GCC 4.0 and newer provides three built-ins for isnan. */ ! # undef isnanl ! # define isnanl(x) __builtin_isnanl ((long double)(x)) ! # elif defined isnan # undef isnanl # define isnanl(x) isnan ((long double)(x)) # endif *** lib/isnanl.h.orig 2008-01-26 15:41:57.0 +0100 --- lib/isnanl.h2008-01-26 15:39:22.0 +0100 *** *** 1,5 /* Test for NaN. !Copyright (C) 2007 Free Software Foundation, Inc. This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by --- 1,5 /* Test for NaN. !Copyright (C) 2007-2008 Free Software Foundation, Inc. This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by *** *** 17,23 #if HAVE_ISNANL /* Get declaration of isnan macro or (older) isnanl function. */ # include math.h ! # ifdef isnan # undef isnanl # define isnanl(x) isnan ((long double)(x)) # endif --- 17,27 #if HAVE_ISNANL /* Get declaration of isnan macro or (older) isnanl function. */ # include math.h ! # if __GNUC__ = 4 !/* GCC 4.0 and newer provides three built-ins for isnan. */ ! # undef isnanl ! # define isnanl(x) __builtin_isnanl ((long double)(x)) ! # elif defined isnan # undef isnanl # define isnanl(x) isnan ((long double)(x)) # endif *** m4/isnanl.m4.orig 2008-01-26 15:41:57.0 +0100 --- m4/isnanl.m42008-01-26 15:39:22.0 +0100 *** *** 1,5 ! # isnanl.m4 serial 5 ! dnl Copyright (C) 2007 Free Software Foundation, Inc. dnl This file is free software; the Free Software Foundation dnl gives unlimited permission to copy and/or distribute it, dnl with or without modifications, as long as this notice is preserved. --- 1,5 ! # isnanl.m4 serial 6 ! dnl Copyright (C)
Re: manpages have a dirty version
Sven Joachim [EMAIL PROTECTED] wrote:
Not a big deal, but I thought I'd mention it anyway: the manpages in
coreutils 6.10 show up the version as
GNU coreutils 6.9.92.4-f088d-dirty
which does not leave a very good impression; regenerating the manpages
when making a stable release seems to be a good idea.
Thanks for reporting that.
The problem is that man/Makefile.am depended on configure.ac
for version string changes. However, the version string is no
longer recorded in that file, so the dependency was nearly useless.
Here's the fix:
2008-01-26 Jim Meyering [EMAIL PROTECTED]
Ensure that each version string change propagates to man pages.
* man/Makefile.am (common_dep): Don't depend on configure.ac for
version changes. Instead, depend on ../VERSION.
(../VERSION): New rule.
* Makefile.am (DISTCLEANFILES): Define.
* GNUmakefile: Update ./VERSION.
* .gitignore: List VERSION.
Reported by Sven Joachim.
diff --git a/.gitignore b/.gitignore
index 6b00458..f5ba5fd 100644
--- a/.gitignore
+++ b/.gitignore
@@ -11,6 +11,7 @@ INSTALL
Makefile
Makefile.in
THANKS-to-translators
+VERSION
aclocal.m4
autom4te.cache
config.cache
diff --git a/GNUmakefile b/GNUmakefile
index 3dc6f15..9502203 100644
--- a/GNUmakefile
+++ b/GNUmakefile
@@ -4,7 +4,7 @@
# It is necessary if you want to build targets usually of interest
# only to the maintainer.
-# Copyright (C) 2001, 2003, 2006-2007 Free Software Foundation, Inc.
+# Copyright (C) 2001, 2003, 2006-2008 Free Software Foundation, Inc.
#
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
@@ -49,6 +49,7 @@ ifeq (0,$(MAKELEVEL))
ifneq ($(_curr-ver),$(VERSION))
$(info INFO: running autoreconf for new version string: $(_curr-ver))
dummy := $(shell rm -rf autom4te.cache; autoreconf)
+ dummy := $(shell echo $(_curr-ver) VERSION)
endif
endif
endif
diff --git a/Makefile.am b/Makefile.am
index 5f9f21a..56f7b85 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -1,6 +1,6 @@
# Make coreutils. -*-Makefile-*-
-# Copyright (C) 1990, 1993-2007 Free Software Foundation, Inc.
+# Copyright (C) 1990, 1993-2008 Free Software Foundation, Inc.
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
@@ -76,6 +76,7 @@ dist-hook:
distcheck-hook:
$(MAKE) my-distcheck
+DISTCLEANFILES = VERSION
MAINTAINERCLEANFILES = THANKS-to-translators
THANKS-to-translators: po/LINGUAS THANKStt.in
( \
diff --git a/man/Makefile.am b/man/Makefile.am
index b7b960e..6cad1a4 100644
--- a/man/Makefile.am
+++ b/man/Makefile.am
@@ -1,6 +1,6 @@
# Make coreutils man pages.-*-Makefile-*-
-# Copyright (C) 2002-2007 Free Software Foundation, Inc.
+# Copyright (C) 2002-2008 Free Software Foundation, Inc.
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
@@ -22,8 +22,8 @@ man_aux = $(dist_man_MANS:.1=.x)
EXTRA_DIST = $(man_aux) $(NO_INSTALL_PROGS_DEFAULT:%=%.x) help2man
MAINTAINERCLEANFILES = $(dist_man_MANS)
-# Depend on configure.ac to get version number changes.
-common_dep = $(top_srcdir)/configure.ac
+# Depend on ../VERSION to get version number changes.
+common_dep = ../VERSION
# Note that arch depends on uname.c
arch.1:$(common_dep) $(srcdir)/arch.x../src/uname.c
@@ -198,3 +198,6 @@ check-programs-vs-x:
|| { echo missing $$p.x 12; status=1; }; \
done; \
exit $$status
+
+../VERSION:
+ echo $(VERSION) [EMAIL PROTECTED] mv [EMAIL PROTECTED] $@
--
1.5.4.rc4.26.g228a
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: sort: memory exhausted with 50GB file
Paul Eggert [EMAIL PROTECTED] wrote: ... Hmm, it sounds like your input data has some very long lines, then. That would explain at least part of your problem, then. 'sort' needs to keep at least two lines in main memory to compare them: if single input lines are many gigabytes long, then 'sort' must consume many gigabytes of memory, regardless of what parameter you specify with '-S'. You can run this to find the maximum line length: wc --max-line-length your-data Ok, first, let me thank Jim, Bob and Paul. Here is the problem in a nutshell: wc is counting with long ints, and the first line of this 50GB file is a string of \0 whose length appears to be negative when counted with long ints. (Details below). I believe that this must be an error in the header file where 'uintmax_t' is defined. I do not know if one can consider this behaviour as a bug in sort, but it seems to me that sort might issue a warning if it encounters 'n0' consecutive null characters in a file. --- I have squeezed out the null characters with tr and am attempting to sort the transformed file. This has shrunk the file from 50GB to 7GB, so I anticipate no problems. I will report back. --- Leo Butler. Details: --- In my original post I mentioned I did count the max line length: $ /usr/bin/wc -L /data/espace/k_400_a.out 107 Here is the censored output of a routine that counts the occurence of all ascii characters: $ ./census /data/espace/k_400_a.out Ascii char Count -- - \0 Null character -1363090872 (snip) The longest line was identified at about line 65x10^6 with 108 chars incl. \n. Ouch! Look at that count of \0. The routine was counting with long ints, so I recompiled it with unsigned longs, and got Ascii char Count -- - \0 Null character 2931876424 (snip) Longest line2931876444 chars at line 1 The counts of \0 are congruent mod LONG_MAX. Apparently, the first line contained roughly 42GB worth of null characters. I have no bleeding idea how this creeped in. LB. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: sort: memory exhausted with 50GB file
Leo Butler [EMAIL PROTECTED] wrote: Paul Eggert [EMAIL PROTECTED] wrote: ... Hmm, it sounds like your input data has some very long lines, then. That would explain at least part of your problem, then. 'sort' needs to keep at least two lines in main memory to compare them: if single input lines are many gigabytes long, then 'sort' must consume many gigabytes of memory, regardless of what parameter you specify with '-S'. You can run this to find the maximum line length: wc --max-line-length your-data ... $ /usr/bin/wc -L /data/espace/k_400_a.out 107 That would have worked if your data really did have the form you originally described. With binary data, you have be careful. E.g., translate all non-printable/space bytes to . before using wc -L: tr -c '[:print:][:space:]' '[.*]' your-data | wc -L ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: sort: memory exhausted with 50GB file
Jim Meyering [EMAIL PROTECTED] wrote: Leo Butler [EMAIL PROTECTED] wrote: Paul Eggert [EMAIL PROTECTED] wrote: ... Hmm, it sounds like your input data has some very long lines, then. That would explain at least part of your problem, then. 'sort' needs to keep at least two lines in main memory to compare them: if single input lines are many gigabytes long, then 'sort' must consume many gigabytes of memory, regardless of what parameter you specify with '-S'. You can run this to find the maximum line length: wc --max-line-length your-data ... $ /usr/bin/wc -L /data/espace/k_400_a.out 107 That would have worked if your data really did have the form you originally described. With binary data, you have be careful. E.g., translate all non-printable/space bytes to . before using wc -L: tr -c '[:print:][:space:]' '[.*]' your-data | wc -L Or, you could simply translate all non-newline bytes to e.g., .: tr -c '\n' '[.*]' your-data | wc -L ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: new snapshot [Re: coreutils 6.9.92 fail to configure on *bsd
On Sat, Jan 26, 2008 at 03:36:23PM +0100, Jim Meyering wrote:
Please see if this makes the test pass:
Avoid cp/preserve-gid test failure on Mac OS 10.5.1 (Darwin 9.1)
* tests/cp/preserve-gid: Set group as well as owner on ..
Reported by Elias Pipping.
diff --git a/tests/cp/preserve-gid b/tests/cp/preserve-gid
index 5f2c050..9537dc0 100755
--- a/tests/cp/preserve-gid
+++ b/tests/cp/preserve-gid
@@ -1,7 +1,7 @@
#!/bin/sh
# Verify that cp -p preserves GID when it is possible.
-# Copyright (C) 2007 Free Software Foundation, Inc.
+# Copyright (C) 2007, 2008 Free Software Foundation, Inc.
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
@@ -61,7 +61,7 @@ if test -z $nameless_uid \
skip_test_ couldn't find a nameless UID or GID
fi
-chown +$nameless_uid .
+chown +$nameless_uid:+0 .
create a0 0 0
create b0 $nameless_uid $nameless_gid1
The test still fails, but it gets a whole lot further :D
-- Elias
% tar xf coreutils-6.10.tar
% cd coreutils-6.10
% patch -p1 ~/foo2.patch
patching file tests/cp/preserve-gid
% ./configure --disable-acl /dev/null
% make -j3 /dev/null
% sudo env VERBOSE=yes NON_ROOT_USERNAME=$USER make check -C tests/cp
TESTS=preserve-gid
make check-TESTS
FAIL: preserve-gid.log
===
1 of 1 tests failed
See tests/cp/test-suite.log
Please report it to bug-coreutils@gnu.org
===
=
GNU coreutils 6.10: tests/cp/test-suite.log
=
1 of 1 tests failed.
.. contents:: :depth: 2
FAIL: preserve-gid.log (exit: 1)
+ cp --version
cp (GNU coreutils) 6.10
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Written by Torbjorn Granlund, David MacKenzie, and Jim Meyering.
++ perl -le 'foreach my $i (1000..16*1024-1) { getpwuid $i or (print $i), exit
}'
+ nameless_uid=1000
++ perl -le 'foreach my $i (1000..16*1024) { getgrgid $i or (print $i), exit }'
+ nameless_gid1=1000
++ perl -le 'foreach my $i (1000+1..16*1024) { getgrgid $i or (print $i), exit
}'
+ nameless_gid2=1001
+ test -z 1000
+ test -z 1000
+ test -z 1001
+ chown +1000:+0 .
+ create a0 0 0
+ echo a0
+ chown +0:+0 a0
+ create b0 1000 1000
+ echo b0
+ chown +1000:+1000 b0
+ create b1 1000 1001
+ echo b1
+ chown +1000:+1001 b1
+ create c0 0 1000
+ echo c0
+ chown +0:+1000 c0
+ create c1 0 1001
+ echo c1
+ chown +0:+1001 c1
+ t0 a0 0 0 cp
+ f=a0
+ shift
+ u=0
+ shift
+ g=0
+ shift
+ rm -f b
+ cp a0 b
++ stat -c '%u %g' b
+ s='0 0'
+ test 'x0 0' '!=' 'x0 0'
+ t0 b0 0 0 cp
+ f=b0
+ shift
+ u=0
+ shift
+ g=0
+ shift
+ rm -f b
+ cp b0 b
++ stat -c '%u %g' b
+ s='0 0'
+ test 'x0 0' '!=' 'x0 0'
+ t0 b1 0 0 cp
+ f=b1
+ shift
+ u=0
+ shift
+ g=0
+ shift
+ rm -f b
+ cp b1 b
++ stat -c '%u %g' b
+ s='0 0'
+ test 'x0 0' '!=' 'x0 0'
+ t0 c0 0 0 cp
+ f=c0
+ shift
+ u=0
+ shift
+ g=0
+ shift
+ rm -f b
+ cp c0 b
++ stat -c '%u %g' b
+ s='0 0'
+ test 'x0 0' '!=' 'x0 0'
+ t0 c1 0 0 cp
+ f=c1
+ shift
+ u=0
+ shift
+ g=0
+ shift
+ rm -f b
+ cp c1 b
++ stat -c '%u %g' b
+ s='0 0'
+ test 'x0 0' '!=' 'x0 0'
+ t0 a0 0 0 cp -p
+ f=a0
+ shift
+ u=0
+ shift
+ g=0
+ shift
+ rm -f b
+ cp -p a0 b
++ stat -c '%u %g' b
+ s='0 0'
+ test 'x0 0' '!=' 'x0 0'
+ t0 b0 1000 1000 cp -p
+ f=b0
+ shift
+ u=1000
+ shift
+ g=1000
+ shift
+ rm -f b
+ cp -p b0 b
++ stat -c '%u %g' b
+ s='1000 1000'
+ test 'x1000 1000' '!=' 'x1000 1000'
+ t0 b1 1000 1001 cp -p
+ f=b1
+ shift
+ u=1000
+ shift
+ g=1001
+ shift
+ rm -f b
+ cp -p b1 b
++ stat -c '%u %g' b
+ s='1000 1001'
+ test 'x1000 1001' '!=' 'x1000 1001'
+ t0 c0 0 1000 cp -p
+ f=c0
+ shift
+ u=0
+ shift
+ g=1000
+ shift
+ rm -f b
+ cp -p c0 b
++ stat -c '%u %g' b
+ s='0 1000'
+ test 'x0 1000' '!=' 'x0 1000'
+ t0 c1 0 1001 cp -p
+ f=c1
+ shift
+ u=0
+ shift
+ g=1001
+ shift
+ rm -f b
+ cp -p c1 b
++ stat -c '%u %g' b
+ s='0 1001'
+ test 'x0 1001' '!=' 'x0 1001'
+ t1 a0 1000 1000 cp
+ f=a0
+ shift
+ u=1000
+ shift
+ g=1000
+ shift
+ t0 a0 1000 1000 setuidgid -g 1000,1001 1000 cp
+ f=a0
+ shift
+ u=1000
+ shift
+ g=1000
+ shift
+ rm -f b
+ setuidgid -g 1000,1001 1000 cp a0 b
++ stat -c '%u %g' b
+ s='1000 0'
+ test 'x1000 0' '!=' 'x1000 1000'
+ echo './preserve-gid: setuidgid -g 1000,1001 1000 cp a0 b: 1000 1000 != 1000
0'
./preserve-gid: setuidgid -g 1000,1001 1000 cp a0 b: 1000 1000 != 1000 0
+ exit 1
+ exit 1
+ st=1
+ cleanup_
+ :
+ d=/Users/pipping/coreutils-6.10/tests/cp/cu-preserve-gid.Z97dkWMGjs
+ cd /Users/pipping/coreutils-6.10/tests/cp
+ chmod -R u+rwx
/Users/pipping/coreutils-6.10/tests/cp/cu-preserve-gid.Z97dkWMGjs
+ rm -rf
[bug #22121] chcon help output refers to lchown system call
Follow-up Comment #2, bug #22121 (project coreutils): Eh? You say that the problem does NOT affect current coreutils. But then you show an example that HAS the bug. What am I missing? In case I wasn't clear: my point was that referring to the system call lchown is wrong. chcon will not use that system call. It will use lsetxattr. (I was looking at version 6.9.92, which I picked from alpha.gnu.org. I discovered it while translating the messages to Swedish.) ___ Reply to this item at: http://savannah.gnu.org/bugs/?22121 ___ Meddelandet skickades via/av Savannah http://savannah.gnu.org/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: new snapshot [Re: coreutils 6.9.92 fail to configure on *bsd
Elias Pipping [EMAIL PROTECTED] wrote:
On Sat, Jan 26, 2008 at 03:36:23PM +0100, Jim Meyering wrote:
Please see if this makes the test pass:
Avoid cp/preserve-gid test failure on Mac OS 10.5.1 (Darwin 9.1)
* tests/cp/preserve-gid: Set group as well as owner on ..
Reported by Elias Pipping.
diff --git a/tests/cp/preserve-gid b/tests/cp/preserve-gid
index 5f2c050..9537dc0 100755
--- a/tests/cp/preserve-gid
+++ b/tests/cp/preserve-gid
@@ -1,7 +1,7 @@
#!/bin/sh
# Verify that cp -p preserves GID when it is possible.
-# Copyright (C) 2007 Free Software Foundation, Inc.
+# Copyright (C) 2007, 2008 Free Software Foundation, Inc.
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
@@ -61,7 +61,7 @@ if test -z $nameless_uid \
skip_test_ couldn't find a nameless UID or GID
fi
-chown +$nameless_uid .
+chown +$nameless_uid:+0 .
create a0 0 0
create b0 $nameless_uid $nameless_gid1
The test still fails, but it gets a whole lot further :D
Good. Progress :)
Here's an additional patch that should get us past the latest failure.
diff --git a/tests/cp/preserve-gid b/tests/cp/preserve-gid
index 9537dc0..15bb51c 100755
--- a/tests/cp/preserve-gid
+++ b/tests/cp/preserve-gid
@@ -33,8 +33,14 @@ t0() {
$@ $f b || exit 1
s=`stat -c '%u %g' b`
if test x$s != x$u $g; then
-echo $0: $* $f b: $u $g != $s 12
-(exit 1); exit 1
+# Allow the actual group to match that of the parent (set to 0 above)
+# if the command was cp.
+if test $@:$s = cp:$u 0; then
+ :
+else
+ echo $0: $* $f b: $u $g != $s 12
+ (exit 1); exit 1
+fi
fi
}
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [bug #22121] chcon help output refers to lchown system call
Göran Uddeborg [EMAIL PROTECTED] wrote: Follow-up Comment #2, bug #22121 (project coreutils): Eh? You say that the problem does NOT affect current coreutils. But then you show an example that HAS the bug. What am I missing? In case I wasn't clear: my point was that referring to the system call lchown is wrong. chcon will not use that system call. It will use lsetxattr. (I was looking at version 6.9.92, which I picked from alpha.gnu.org. I discovered it while translating the messages to Swedish.) Eh? indeed! How odd. I wonder what came over me :-) I've just removed that line from --help output. Thank you! ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: new snapshot [Re: coreutils 6.9.92 fail to configure on *bsd
On Sat, Jan 26, 2008 at 05:34:17PM +0100, Jim Meyering wrote:
Here's an additional patch that should get us past the latest failure.
Unfortunately, it doesn't.
diff --git a/tests/cp/preserve-gid b/tests/cp/preserve-gid
index 9537dc0..15bb51c 100755
--- a/tests/cp/preserve-gid
+++ b/tests/cp/preserve-gid
@@ -33,8 +33,14 @@ t0() {
$@ $f b || exit 1
s=`stat -c '%u %g' b`
if test x$s != x$u $g; then
-echo $0: $* $f b: $u $g != $s 12
-(exit 1); exit 1
+# Allow the actual group to match that of the parent (set to 0 above)
+# if the command was cp.
+if test $@:$s = cp:$u 0; then
+ :
+else
+ echo $0: $* $f b: $u $g != $s 12
+ (exit 1); exit 1
+fi
fi
}
-- Elias
% tar xf coreutils-6.10.tar
% cd coreutils-6.10
% patch -p1 ~/foo2.patch
patching file tests/cp/preserve-gid
% patch -p1 ~/foo3.patch
patching file tests/cp/preserve-gid
% ./configure --disable-acl /dev/null
% make -j3 /dev/null
% sudo env VERBOSE=yes NON_ROOT_USERNAME=$USER make check -C tests/cp
TESTS=preserve-gid
make check-TESTS
FAIL: preserve-gid.log
===
1 of 1 tests failed
See tests/cp/test-suite.log
Please report it to bug-coreutils@gnu.org
===
=
GNU coreutils 6.10: tests/cp/test-suite.log
=
1 of 1 tests failed.
.. contents:: :depth: 2
FAIL: preserve-gid.log (exit: 1)
+ cp --version
cp (GNU coreutils) 6.10
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Written by Torbjorn Granlund, David MacKenzie, and Jim Meyering.
++ perl -le 'foreach my $i (1000..16*1024-1) { getpwuid $i or (print $i), exit
}'
+ nameless_uid=1000
++ perl -le 'foreach my $i (1000..16*1024) { getgrgid $i or (print $i), exit }'
+ nameless_gid1=1000
++ perl -le 'foreach my $i (1000+1..16*1024) { getgrgid $i or (print $i), exit
}'
+ nameless_gid2=1001
+ test -z 1000
+ test -z 1000
+ test -z 1001
+ chown +1000:+0 .
+ create a0 0 0
+ echo a0
+ chown +0:+0 a0
+ create b0 1000 1000
+ echo b0
+ chown +1000:+1000 b0
+ create b1 1000 1001
+ echo b1
+ chown +1000:+1001 b1
+ create c0 0 1000
+ echo c0
+ chown +0:+1000 c0
+ create c1 0 1001
+ echo c1
+ chown +0:+1001 c1
+ t0 a0 0 0 cp
+ f=a0
+ shift
+ u=0
+ shift
+ g=0
+ shift
+ rm -f b
+ cp a0 b
++ stat -c '%u %g' b
+ s='0 0'
+ test 'x0 0' '!=' 'x0 0'
+ t0 b0 0 0 cp
+ f=b0
+ shift
+ u=0
+ shift
+ g=0
+ shift
+ rm -f b
+ cp b0 b
++ stat -c '%u %g' b
+ s='0 0'
+ test 'x0 0' '!=' 'x0 0'
+ t0 b1 0 0 cp
+ f=b1
+ shift
+ u=0
+ shift
+ g=0
+ shift
+ rm -f b
+ cp b1 b
++ stat -c '%u %g' b
+ s='0 0'
+ test 'x0 0' '!=' 'x0 0'
+ t0 c0 0 0 cp
+ f=c0
+ shift
+ u=0
+ shift
+ g=0
+ shift
+ rm -f b
+ cp c0 b
++ stat -c '%u %g' b
+ s='0 0'
+ test 'x0 0' '!=' 'x0 0'
+ t0 c1 0 0 cp
+ f=c1
+ shift
+ u=0
+ shift
+ g=0
+ shift
+ rm -f b
+ cp c1 b
++ stat -c '%u %g' b
+ s='0 0'
+ test 'x0 0' '!=' 'x0 0'
+ t0 a0 0 0 cp -p
+ f=a0
+ shift
+ u=0
+ shift
+ g=0
+ shift
+ rm -f b
+ cp -p a0 b
++ stat -c '%u %g' b
+ s='0 0'
+ test 'x0 0' '!=' 'x0 0'
+ t0 b0 1000 1000 cp -p
+ f=b0
+ shift
+ u=1000
+ shift
+ g=1000
+ shift
+ rm -f b
+ cp -p b0 b
++ stat -c '%u %g' b
+ s='1000 1000'
+ test 'x1000 1000' '!=' 'x1000 1000'
+ t0 b1 1000 1001 cp -p
+ f=b1
+ shift
+ u=1000
+ shift
+ g=1001
+ shift
+ rm -f b
+ cp -p b1 b
++ stat -c '%u %g' b
+ s='1000 1001'
+ test 'x1000 1001' '!=' 'x1000 1001'
+ t0 c0 0 1000 cp -p
+ f=c0
+ shift
+ u=0
+ shift
+ g=1000
+ shift
+ rm -f b
+ cp -p c0 b
++ stat -c '%u %g' b
+ s='0 1000'
+ test 'x0 1000' '!=' 'x0 1000'
+ t0 c1 0 1001 cp -p
+ f=c1
+ shift
+ u=0
+ shift
+ g=1001
+ shift
+ rm -f b
+ cp -p c1 b
++ stat -c '%u %g' b
+ s='0 1001'
+ test 'x0 1001' '!=' 'x0 1001'
+ t1 a0 1000 1000 cp
+ f=a0
+ shift
+ u=1000
+ shift
+ g=1000
+ shift
+ t0 a0 1000 1000 setuidgid -g 1000,1001 1000 cp
+ f=a0
+ shift
+ u=1000
+ shift
+ g=1000
+ shift
+ rm -f b
+ setuidgid -g 1000,1001 1000 cp a0 b
++ stat -c '%u %g' b
+ s='1000 0'
+ test 'x1000 0' '!=' 'x1000 1000'
+ test 'setuidgid -g 1000,1001 1000 cp:1000 0' = 'cp:1000 0'
+ echo './preserve-gid: setuidgid -g 1000,1001 1000 cp a0 b: 1000 1000 != 1000
0'
./preserve-gid: setuidgid -g 1000,1001 1000 cp a0 b: 1000 1000 != 1000 0
+ exit 1
+ exit 1
+ st=1
+ cleanup_
+ :
+ d=/Users/pipping/coreutils-6.10/tests/cp/cu-preserve-gid.cZqpAQhXfq
+ cd /Users/pipping/coreutils-6.10/tests/cp
+ chmod -R u+rwx
/Users/pipping/coreutils-6.10/tests/cp/cu-preserve-gid.cZqpAQhXfq
+ rm -rf /Users/pipping/coreutils-6.10/tests/cp/cu-preserve-gid.cZqpAQhXfq
+ exit 1
make[2]: *** [test-suite.log] Error 1
make[1]: *** [check-TESTS] Error 2
make: *** [check-am] Error 2
%
--- preserve-gid_test_new 2008-01-26 16:48:43 +0100
+++
Re: new snapshot [Re: coreutils 6.9.92 fail to configure on *bsd
Elias Pipping [EMAIL PROTECTED] wrote:
On Sat, Jan 26, 2008 at 05:34:17PM +0100, Jim Meyering wrote:
Here's an additional patch that should get us past the latest failure.
Unfortunately, it doesn't.
...
++ stat -c '%u %g' b
+ s='1000 0'
+ test 'x1000 0' '!=' 'x1000 1000'
+ test 'setuidgid -g 1000,1001 1000 cp:1000 0' = 'cp:1000 0'
+ echo './preserve-gid: setuidgid -g 1000,1001 1000 cp a0 b: 1000 1000 !=
1000 0'
./preserve-gid: setuidgid -g 1000,1001 1000 cp a0 b: 1000 1000 != 1000 0
But it came close :-)
Thanks for the quick feedback.
I should have matched the whole command, from setuidgid -g...cp,
not just cp.
Here's a better one:
* tests/cp/preserve-gid: accommodate Darwin9 oddity.
diff --git a/tests/cp/preserve-gid b/tests/cp/preserve-gid
index 9537dc0..82ee861 100755
--- a/tests/cp/preserve-gid
+++ b/tests/cp/preserve-gid
@@ -33,8 +33,15 @@ t0() {
$@ $f b || exit 1
s=`stat -c '%u %g' b`
if test x$s != x$u $g; then
-echo $0: $* $f b: $u $g != $s 12
-(exit 1); exit 1
+# Allow the actual group to match that of the parent directory
+# (it was set to 0 above) if the command was cp.
+case $@:$s in
+ * cp:$u 0) ;;
+ *)
+ echo $0: $* $f b: $u $g != $s 12
+ (exit 1); exit 1
+ ;;
+esac
fi
}
--
1.5.4.rc4.26.g228a
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
mv symlink-to-dir/, debian bug feed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I've noticed that Jim just committed a patch based on a bug originally reported through the debian tracker without any additional mention here: http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commit;h=c0c8685 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=343652 But regarding the patch, I'm wondering if an Austin Group interpretation is needed here. The next draft for POSIX has already tightened the wording to make it clear that rename(dir, newdir/) must fail with ENOTDIR if newdir is not already a directory. Likewise, it clarifies that 'mv dir newdir/' must fail (oops - coreutils 6.10 doesn't do that). However, I still don't see any clarification on whether the Linux behavior of rename(symlink-to-dir/, newname) failing with ENOTDIR is valid. Meanwhile, would it be worth subscribing bug-coreutils to the debian bug feed list? That way, this list would see bugs as they are reported, and others besides Jim will be able to chime in with advice. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHm3eo84KuGfSFAYARAvdMAKCT/iwkMwEROIDD0tbHquDGYCQCIwCeJ4NA dHNQQ1bC/uw0tsiyUfdaDLg= =/rb7 -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv symlink-to-dir/, debian bug feed
Eric Blake [EMAIL PROTECTED] wrote: I've noticed that Jim just committed a patch based on a bug originally reported through the debian tracker without any additional mention here: http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commit;h=c0c8685 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=343652 Thanks. But regarding the patch, I'm wondering if an Austin Group interpretation is needed here. The next draft for POSIX has already tightened the IMHO, it is needed. If you're willing to broach the subject, that'd be great. wording to make it clear that rename(dir, newdir/) must fail with ENOTDIR if newdir is not already a directory. Likewise, it clarifies that 'mv dir newdir/' must fail (oops - coreutils 6.10 doesn't do that). However, I still don't see any clarification on whether the Linux behavior of rename(symlink-to-dir/, newname) failing with ENOTDIR is valid. As you probably realize, that is behavior straight from glibc and the kernel rename syscall. Meanwhile, would it be worth subscribing bug-coreutils to the debian bug feed list? That way, this list would see bugs as they are reported, and others besides Jim will be able to chime in with advice. I know Bob Proulx is already subscribed there. Some of the traffic would not be interesting, i.e., a message announcing that a bug is closed, or tagged -- but those are easy to skip. Overall, I think it would be better for both Debian and GNU. We can always try, and if it doesn't work out, remove it later. Bob, Michael, what do you think? ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
rename(symlink-to-dir/, name) behavior
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I know that draft 4 added some clarification on rename(2) (and mv(1)) behavior on path resolution. However, there is still an ambiguous situation, which I don't see documented, and I would like some consensus before writing an aardvark. This issue was raised as a report against GNU coreutils: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=343652. Consider: $ mkdir A $ ln -s A B $ mv B/ C On at least Solaris and and FreeBSD, the call resolves B/ to the name A, finds that it is a directory, and moves the directory to the new name C. This is somewhat surprising to novice users, since B still exists, but is now a broken link. On Linux, the call recognizes that B is a symlink (even though the trailing slash would resolve to a directory), and fails with ENOTDIR. My strict reading of the current wording in draft 4 does not permit Linux' behavior (even though it is more useful, in my opinion), since the trailing slash on B/ means that the old argument names a directory by the rewritten path resolution rules in XBD 4.12 (line 3008). Do we want to support both behaviors, or even add an additional restriction at line 56800 (and thus make the current Solaris and FreeBSD implementation buggy), that for rename, an 'old' argument with a trailing slash must be a directory (and not a symlink to a directory)? - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHm3zS84KuGfSFAYARAqLQAJ0WnR+89JfM/deFcdSJ1oy84tq1KACfctmu wEjo+2fwORPoM78Jn5snOps= =EBwm -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Bug#388684: coreutils: info ls opens the man page, not the info documentation
[EMAIL PROTECTED] (Bob Proulx) wrote: Jim Meyering wrote: Michael Stone wrote: The full documentation for ls is maintained as a Texinfo manual. If the info and ls programs are properly installed at your site (on debian they aren't), the command info ls should give you access to the complete manual. The info documentation can also be read at http://www.gnu.org/software/coreutils/manual/html_node/index.html The down side to this is that link won't be in sync with the debian package, but I just can't think of a better answer at this point. Another down side: it requires web access. I don't prefer it either. People who are inclined to use web documentation will already be using it. People who don't will be annoyed by it. (I am in the latter camp.) What do you think of info coreutils ls? It doesn't work for info coreutils pr (because info matches the pr in the earlier Printing text node, but I suppose I could special case that one and have info coreutils 'pr invocation'. I think there were a few other ones like that, but getting ~96/100 is a lot better than 0/100. I think it should be the normal case for all of the coreutils commands and not the special case just for pr. Why not have this done uniformly? info coreutils ls invocation To me that looks nice enough to be used for all of the commands. Most people would simply cut and paste it directly without typing it so the extra characters wouldn't be a burden. I think that should work for all of the commands without any special cases. And if it doesn't, then it should. I've just applied this: 2008-01-26 Jim Meyering [EMAIL PROTECTED] Emit info coreutils 'PROG invocation' into the man page, rather than just info PROG. The latter would often fail or simply display the man page. * man/help2man: Change the template. Prompted by http://bugs.debian.org/399684 diff --git a/man/help2man b/man/help2man index e28d2a4..1bc12cf 100755 --- a/man/help2man +++ b/man/help2man @@ -1,7 +1,7 @@ #!/usr/bin/perl -w # Generate a short man page from --help and --version output. -# Copyright (C) 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004 +# Copyright (C) 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2008 # Free Software Foundation, Inc. # This program is free software: you can redistribute it and/or modify @@ -567,7 +567,7 @@ and .B %s programs are properly installed at your site, the command .IP -.B info %s +.B info coreutils '%s invocation' .PP should give you access to the complete manual. EOT -- 1.5.4.rc4.26.g228a ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: new snapshot [Re: coreutils 6.9.92 fail to configure on *bsd
On Sat, Jan 26, 2008 at 07:06:58PM +0100, Jim Meyering wrote:
Here's a better one:
More progress! (still fails)
* tests/cp/preserve-gid: accommodate Darwin9 oddity.
diff --git a/tests/cp/preserve-gid b/tests/cp/preserve-gid
index 9537dc0..82ee861 100755
--- a/tests/cp/preserve-gid
+++ b/tests/cp/preserve-gid
@@ -33,8 +33,15 @@ t0() {
$@ $f b || exit 1
s=`stat -c '%u %g' b`
if test x$s != x$u $g; then
-echo $0: $* $f b: $u $g != $s 12
-(exit 1); exit 1
+# Allow the actual group to match that of the parent directory
+# (it was set to 0 above) if the command was cp.
+case $@:$s in
+ * cp:$u 0) ;;
+ *)
+ echo $0: $* $f b: $u $g != $s 12
+ (exit 1); exit 1
+ ;;
+esac
fi
}
--
1.5.4.rc4.26.g228a
-- Elias
% tar xf coreutils-6.10.tar
% cd coreutils-6.10
% patch -p1 ~/foo2.patch
patching file tests/cp/preserve-gid
% patch -p1 ~/foo3a.patch
patching file tests/cp/preserve-gid
% ./configure --disable-acl /dev/null
% make -j3 /dev/null
% sudo env VERBOSE=yes NON_ROOT_USERNAME=$USER make check -C tests/cp
TESTS=preserve-gid
make check-TESTS
FAIL: preserve-gid.log
===
1 of 1 tests failed
See tests/cp/test-suite.log
Please report it to bug-coreutils@gnu.org
===
=
GNU coreutils 6.10: tests/cp/test-suite.log
=
1 of 1 tests failed.
.. contents:: :depth: 2
FAIL: preserve-gid.log (exit: 1)
+ cp --version
cp (GNU coreutils) 6.10
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Written by Torbjorn Granlund, David MacKenzie, and Jim Meyering.
++ perl -le 'foreach my $i (1000..16*1024-1) { getpwuid $i or (print $i), exit
}'
+ nameless_uid=1000
++ perl -le 'foreach my $i (1000..16*1024) { getgrgid $i or (print $i), exit }'
+ nameless_gid1=1000
++ perl -le 'foreach my $i (1000+1..16*1024) { getgrgid $i or (print $i), exit
}'
+ nameless_gid2=1001
+ test -z 1000
+ test -z 1000
+ test -z 1001
+ chown +1000:+0 .
+ create a0 0 0
+ echo a0
+ chown +0:+0 a0
+ create b0 1000 1000
+ echo b0
+ chown +1000:+1000 b0
+ create b1 1000 1001
+ echo b1
+ chown +1000:+1001 b1
+ create c0 0 1000
+ echo c0
+ chown +0:+1000 c0
+ create c1 0 1001
+ echo c1
+ chown +0:+1001 c1
+ t0 a0 0 0 cp
+ f=a0
+ shift
+ u=0
+ shift
+ g=0
+ shift
+ rm -f b
+ cp a0 b
++ stat -c '%u %g' b
+ s='0 0'
+ test 'x0 0' '!=' 'x0 0'
+ t0 b0 0 0 cp
+ f=b0
+ shift
+ u=0
+ shift
+ g=0
+ shift
+ rm -f b
+ cp b0 b
++ stat -c '%u %g' b
+ s='0 0'
+ test 'x0 0' '!=' 'x0 0'
+ t0 b1 0 0 cp
+ f=b1
+ shift
+ u=0
+ shift
+ g=0
+ shift
+ rm -f b
+ cp b1 b
++ stat -c '%u %g' b
+ s='0 0'
+ test 'x0 0' '!=' 'x0 0'
+ t0 c0 0 0 cp
+ f=c0
+ shift
+ u=0
+ shift
+ g=0
+ shift
+ rm -f b
+ cp c0 b
++ stat -c '%u %g' b
+ s='0 0'
+ test 'x0 0' '!=' 'x0 0'
+ t0 c1 0 0 cp
+ f=c1
+ shift
+ u=0
+ shift
+ g=0
+ shift
+ rm -f b
+ cp c1 b
++ stat -c '%u %g' b
+ s='0 0'
+ test 'x0 0' '!=' 'x0 0'
+ t0 a0 0 0 cp -p
+ f=a0
+ shift
+ u=0
+ shift
+ g=0
+ shift
+ rm -f b
+ cp -p a0 b
++ stat -c '%u %g' b
+ s='0 0'
+ test 'x0 0' '!=' 'x0 0'
+ t0 b0 1000 1000 cp -p
+ f=b0
+ shift
+ u=1000
+ shift
+ g=1000
+ shift
+ rm -f b
+ cp -p b0 b
++ stat -c '%u %g' b
+ s='1000 1000'
+ test 'x1000 1000' '!=' 'x1000 1000'
+ t0 b1 1000 1001 cp -p
+ f=b1
+ shift
+ u=1000
+ shift
+ g=1001
+ shift
+ rm -f b
+ cp -p b1 b
++ stat -c '%u %g' b
+ s='1000 1001'
+ test 'x1000 1001' '!=' 'x1000 1001'
+ t0 c0 0 1000 cp -p
+ f=c0
+ shift
+ u=0
+ shift
+ g=1000
+ shift
+ rm -f b
+ cp -p c0 b
++ stat -c '%u %g' b
+ s='0 1000'
+ test 'x0 1000' '!=' 'x0 1000'
+ t0 c1 0 1001 cp -p
+ f=c1
+ shift
+ u=0
+ shift
+ g=1001
+ shift
+ rm -f b
+ cp -p c1 b
++ stat -c '%u %g' b
+ s='0 1001'
+ test 'x0 1001' '!=' 'x0 1001'
+ t1 a0 1000 1000 cp
+ f=a0
+ shift
+ u=1000
+ shift
+ g=1000
+ shift
+ t0 a0 1000 1000 setuidgid -g 1000,1001 1000 cp
+ f=a0
+ shift
+ u=1000
+ shift
+ g=1000
+ shift
+ rm -f b
+ setuidgid -g 1000,1001 1000 cp a0 b
++ stat -c '%u %g' b
+ s='1000 0'
+ test 'x1000 0' '!=' 'x1000 1000'
+ case $@:$s in
+ t1 b0 1000 1000 cp
+ f=b0
+ shift
+ u=1000
+ shift
+ g=1000
+ shift
+ t0 b0 1000 1000 setuidgid -g 1000,1001 1000 cp
+ f=b0
+ shift
+ u=1000
+ shift
+ g=1000
+ shift
+ rm -f b
+ setuidgid -g 1000,1001 1000 cp b0 b
++ stat -c '%u %g' b
+ s='1000 0'
+ test 'x1000 0' '!=' 'x1000 1000'
+ case $@:$s in
+ t1 b1 1000 1000 cp
+ f=b1
+ shift
+ u=1000
+ shift
+ g=1000
+ shift
+ t0 b1 1000 1000 setuidgid -g 1000,1001 1000 cp
+ f=b1
+ shift
+ u=1000
+ shift
+ g=1000
+ shift
+ rm -f b
+ setuidgid -g 1000,1001 1000 cp b1 b
++ stat -c '%u %g' b
+ s='1000 0'
+ test 'x1000 0' '!=' 'x1000 1000'
+ case $@:$s in
+ t1 c0 1000 1000 cp
+ f=c0
+ shift
Re: mv symlink-to-dir/, debian bug feed
On Sat, Jan 26, 2008 at 07:23:08PM +0100, Jim Meyering wrote: I know Bob Proulx is already subscribed there. Some of the traffic would not be interesting, i.e., a message announcing that a bug is closed, or tagged -- but those are easy to skip. Overall, I think it would be better for both Debian and GNU. We can always try, and if it doesn't work out, remove it later. Bob, Michael, what do you think? Fine with me. Subscription options are here: http://www.debian.org/doc/manuals/developers-reference/ch-resources.en.html#s-pkg-tracking-system I think if bts is chosen, you'd get only bug reports without the extraneous status change emails. Mike Stone ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Bug#388684: coreutils: info ls opens the man page, not the info documentation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Jim Meyering on 1/26/2008 11:39 AM: | | I've just applied this: | | 2008-01-26 Jim Meyering [EMAIL PROTECTED] | | Emit info coreutils 'PROG invocation' into the man page, | rather than just info PROG. The latter would often fail | or simply display the man page. | * man/help2man: Change the template. | Prompted by http://bugs.debian.org/399684 However, the info manual recommends: | So, there is a convention to name such sections with a phrase | beginning with the word `Invoking', as in `Invoking Emacs'; this way, | users can find the section easily. Maybe the better fix would be renaming all the nodes in coreutils.texi to comply with this convention? - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHm4RH84KuGfSFAYARAopMAKCa9XH+SpTrVS5BhPyywFvHApQn9ACeJ7TI kfl79LSgDAdZlrt5kU3OrX8= =a5cT -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Bug#388684: coreutils: info ls opens the man page, not the info documentation
Eric Blake [EMAIL PROTECTED] wrote: According to Jim Meyering on 1/26/2008 11:39 AM: | | I've just applied this: | | 2008-01-26 Jim Meyering [EMAIL PROTECTED] | | Emit info coreutils 'PROG invocation' into the man page, | rather than just info PROG. The latter would often fail | or simply display the man page. | * man/help2man: Change the template. | Prompted by http://bugs.debian.org/399684 However, the info manual recommends: | So, there is a convention to name such sections with a phrase | beginning with the word `Invoking', as in `Invoking Emacs'; this way, | users can find the section easily. Maybe the better fix would be renaming all the nodes in coreutils.texi to comply with this convention? Hi Karl, Just wondering if you have anything to say anything about this. I'm not inclined to change the node names, because they've worked just fine for so long, and there might be code (or muscle memory :-) that requires the current names. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: sort: memory exhausted with 50GB file
Thank you for your help. Leo Butler ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Options --enable{,-no}-install-program
James Youngman [EMAIL PROTECTED] wrote:
On Jan 8, 2008 5:46 PM, Jim Meyering [EMAIL PROTECTED] wrote:
If you're really motivated, there's another minor problem:
the include/exclude mechanism operates only on bin_PROGRAMS,
and not bin_SCRIPTS. That means --enable-no-install-program=groups
doesn't work, since groups is a script.
I had a go at this and didn't come up with a result I found pleasing.
So instead I took a sledgehammer to the walnut. The patch is attached
(sorry, but it's safer that way because of my non-configurable
tab-mangling mail client) and the ChangeLog entry is appended.
Please note that I added a NEWS file entry; no doubt you will need to
fix the version number in there, the file format demands one but I had
no idea what to use.
If you don't like the change, let me know and I'll resubmit just the
segv fix as a separate patch.
After a partial review and tweaks to make make distcheck pass,
I have the patch below. Most of the changes so far:
- A few of the files had trailing spaces: removed them
- converted all TABs in src/gr*.[ch] to sequences of spaces
and added the Local variables: block at end of each new .c file.
- factored out the duplication in the coreutils.texi change
- added new names to POTFILES.in
- updated AUTHORS
- while I know too well how bad stdio is, I'm tempted to remove the
new tests of each printf return value. I noticed that you check
those while not checking putchar.
I'll let this sit for a couple more days...
From 028f9bf4413cddd999c527677374551ea743d249 Mon Sep 17 00:00:00 2001
From: James Youngman [EMAIL PROTECTED]
Date: Fri, 25 Jan 2008 16:05:52 +
Subject: [PATCH] Replace groups.sh with groups.c.
* src/groups.c (main): New file, replacing groups.sh.
* src/group-list.c, src/group-list.h: New files, factored out of id.c,
implementing the functionality that id and groups have in common.
* src/id.c (print_full_info): Avoid a segfault when trying to print
an error message if getgroups fails.
(print_group_list): Move to group-list.c.
(print_group): Likewise.
* man/Makefile.am: When building groups.1, obtain the help text
from src/groups.c, not src/groups.sh.
* doc/coreutils.texi (groups: Print group names a user is in):
Explain why groups and groups $(id -un) give different results
in existing login sessions after you change the group database.
(id: Print user identity): Likewise for id.
* po/POTFILES.in: Add src/group-list.c and src/groups.c.
* NEWS: mention this.
* AUTHORS: Update.
---
AUTHORS|2 +-
NEWS |7 +++
doc/coreutils.texi | 14 +-
man/Makefile.am|2 +-
po/POTFILES.in |4 +-
src/Makefile.am| 21 ++--
src/group-list.c | 134 +
src/group-list.h | 19 +++
src/groups.c | 153
src/groups.sh | 84
src/id.c | 108 ++---
11 files changed, 363 insertions(+), 185 deletions(-)
create mode 100644 src/group-list.c
create mode 100644 src/group-list.h
create mode 100644 src/groups.c
delete mode 100755 src/groups.sh
diff --git a/AUTHORS b/AUTHORS
index 200e141..807857f 100644
--- a/AUTHORS
+++ b/AUTHORS
@@ -31,7 +31,7 @@ false: Jim Meyering
fmt: Ross Paterson
fold: David MacKenzie
ginstall: David MacKenzie
-groups: David MacKenzie
+groups: David MacKenzie, James Youngman
head: David MacKenzie, Jim Meyering
hostid: Jim Meyering
hostname: Jim Meyering
diff --git a/NEWS b/NEWS
index 4811296..2a9a148 100644
--- a/NEWS
+++ b/NEWS
@@ -1,5 +1,12 @@
GNU coreutils NEWS-*- outline -*-
+* Noteworthy changes in release 6.11 (2008-??-??) [stable]
+
+ configure --enable-no-install-program=groups now works.
+
+ groups -- foo no longer generates a spurious error about the
+ nonexistent group --.
+
* Noteworthy changes in release 6.10 (2008-01-22) [stable]
** Bug fixes
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index 0de8560..c1300fb 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -12225,6 +12225,15 @@ Print only the user ID.
@exitstatus
[EMAIL PROTECTED] primaryAndSupplementaryGroups{cmd,arg}
+Primary and supplementary groups for a process are normally inherited
+from its parent and are usually unchanged since login. This means
+that if you change the group database after logging in, @command{\cmd\}
+will not reflect your changes within your existing login session.
+Running @command{\cmd\} with a \arg\ causes the user and group
+database to be consulted afresh, and so will give a different result.
[EMAIL PROTECTED] macro
[EMAIL PROTECTED],user argument}
@node logname invocation
@section @command{logname}: Print current login name
@@ -12274,7 +12283,8 @@ options}.
groups for each given @var{username}, or the current process if no names
are given. If more than one name is
Re: Options --enable{,-no}-install-program
On Jan 26, 2008 10:55 PM, Jim Meyering [EMAIL PROTECTED] wrote: - factored out the duplication in the coreutils.texi change Interesting technique, I'll remember it. - while I know too well how bad stdio is, I'm tempted to remove the new tests of each printf return value. I noticed that you check those while not checking putchar. Yes, being _inconsistently_ paranoid is unuseful. Looking at an unchecked printf() call used not to bother me until after I worked on GNC CSSC for a while. In CSSC, an unchecked printf can cause data-loss in your version control archive, which is not so good. This sort of thing is much less of an issue for programs like groups. If you wanted to remove those checks I would not object. James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Options --enable{,-no}-install-program
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Jim Meyering on 1/26/2008 3:55 PM:
| + groups -- foo no longer generates a spurious error about the
| + nonexistent group --.
Huh? That's been fixed for some time now (Sept 2006):
http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=b7c315c
| - while I know too well how bad stdio is, I'm tempted to remove the
| new tests of each printf return value. I noticed that you check
| those while not checking putchar.
That's where the combination of xprintf and close-stdout will help -
xprintf catches any errors that don't set the ferror bit, and all
remaining errors (all putchar errors, and most printf errors) touch the
ferror bit and are then caught by close-stdout. In other words,
| +int
| +main (int argc, char **argv)
| +{
...
| +
| + atexit (close_stdout);
| +
because of this call...
| +
| + if (printf (%s : , argv[optind]) 0)
| +{
| + write_error ();
| + ok = false;
| +}
You can use xprintf, and the above becomes one line instead of five...
| + if (EOF == putchar ('\n'))
| +{
| + write_error ();
| + ok = false;
| +}
And the above need only be 'putchar ('\n');' instead of five lines, and
you don't need the helper function write_error().
| +}
| +}
| +
| + exit (ok ? EXIT_SUCCESS : EXIT_FAILURE);
And if you get here, you can use simply 'exit EXIT_SUCCESS;' - the atexit
handler will take care of correcting the exit status if there was any
write error in the meantime.
| -print_user (use_real ? ruid : euid);
| +{
| + print_user (use_real ? ruid : euid);
| +}
Why are you making these cosmetic changes, with no other change in the
code? GNU Coding Standards recommend eliding the braces for single-line
statements (yes, it is a style that not everyone likes, because you then
have to remember to add braces if you add a statement, but consistency
looks nicer).
- --
Don't work too hard, make some time for fun as well!
Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHm8LL84KuGfSFAYARAhqLAKCIGzZxagwv6uKrQZNd0Vfo1hq7XACfX2kU
yz4KQydFFZcObH58+8zVOFc=
=yJqQ
-END PGP SIGNATURE-
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Coreutils binary sizes over time
Hi, Out of a bit of boredom (and avoiding trying to fix a VHDL problem) I decided to graph the sizes of a few of the binaries from coreutils, as packaged by debian over time (I've included fileutils/shellutils). At: http://www.treblig.org/pics/debianbinarysizes.png you can see a graph showing ls, du, df, true, and chmod over about 10 years. The raw data is here: http://www.treblig.org/data/debiansizes.csv All of these are the Linux/x86 binary packages and all binaries are ELF, stripped, with shared libs. I've not made much attempt to analyse why things are growing; although the fun one is the size of 'true' that used to be a tiny shell script. It's a bit scary that 'true' has gone from a 395 byte script to a 22k binary in 10 years (even the first binary version I have is under 5k); I can imagine that some of the other binaries probably have more to do with system interaction (e.g. ls gaining selinux support). Dave -- -Open up your eyes, open up your mind, open up your code --- / Dr. David Alan Gilbert| Running GNU/Linux on Alpha,68K| Happy \ \ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC HPPA | In Hex / \ _|_ http://www.treblig.org |___/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Options --enable{,-no}-install-program
On Jan 26, 2008 11:31 PM, Eric Blake [EMAIL PROTECTED] wrote:
[ unknown group -- ]
Huh? That's been fixed for some time now (Sept 2006):
http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=b7c315c
Yes, sorry, I was confusing /usr/bin/groups and ./groups.
| -print_user (use_real ? ruid : euid);
| +{
| + print_user (use_real ? ruid : euid);
| +}
Why are you making these cosmetic changes, with no other change in the
code? GNU Coding Standards recommend eliding the braces for single-line
statements (yes, it is a style that not everyone likes, because you then
have to remember to add braces if you add a statement, but consistency
looks nicer).
It's just that I preffered
if (condition)
{
compound
}
else
{
foo
}
else
{
compound
}
... to ...
if (condition)
{
compound
}
else
foo
else
{
compound
}
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
