Re: coreutils-6.11 released

[Jim Meyering]

Elbert Pol <[EMAIL PROTECTED]> wrote:
...
> Hope it's fixable :)

Anything is fixable ;-)

> Jim Meyering wrote:
>> Elbert Pol<[EMAIL PROTECTED]>  wrote:
...
>>> make.exe[2]: Entering directory `U:/coreutils-6.11/man'
>>> make.exe[2]: *** No rule to make target `uname.1
>>> ', needed by `all-am'.  Stop.

Hi Elbert,

Thanks for the details.
I should have seen it the first time:
The mention of uname.1 includes something fishy that makes the trailing
"'" appear on the next line.  More carriage return problems.

Here's a snapshot with the fix:

  http://meyering.net/cu/coreutils-6.11.11-0bc881.tar.lzma

Here's the patch I expect to push, once
you confirm it solves that problem:

>From 0bc8813b1e40435ced17c555149e26c5aadbdda6 Mon Sep 17 00:00:00 2001
From: Jim Meyering <[EMAIL PROTECTED]>
Date: Tue, 22 Apr 2008 10:52:37 +0200
Subject: [PATCH] Accommodate building on OS/2 (www.ecomstation.com Ecs v2 rc4)

* configure.ac: Filter out carriage returns in more places.
Reported by Elbert Pol, details here:
http://thread.gmane.org/gmane.org.fsf.announce/867/focus=13332

Signed-off-by: Jim Meyering <[EMAIL PROTECTED]>
---
 configure.ac |7 ---
 1 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/configure.ac b/configure.ac
index 4cd0d7c..adf2903 100644
--- a/configure.ac
+++ b/configure.ac
@@ -259,7 +259,7 @@ mk="$srcdir/src/Makefile.am"
 v=EXTRA_PROGRAMS
 for gl_i in `sed -n '/^'$v' =/,/[[^\]]$/p' $mk \
 | sed 's/^  *//;/^\$.*/d;/^'$v' =/d' \
-| tr -s '\\012' '  '`; do
+| tr -s '\\015\\012' '  '`; do
   gl_ADD_PROG([optional_bin_progs], $gl_i)
 done

@@ -310,10 +310,11 @@ case " $optional_bin_progs " in
   *)INSTALL_SU=no ;;
 esac

-MAN=`echo "$optional_bin_progs "|sed 's/ /.1 /g;s/ $//'`
+MAN=`echo "$optional_bin_progs "|sed 's/ /.1 /g;s/ $//'|tr -d '\\015\\012'`

 # 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 
'\012' ' '; echo`
+MAN=`for m in $MAN; do test $m = ginstall.1 && m=install.1; echo $m; done \
+  | 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
--
1.5.5.76.gae22a


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

Re: Bash vs. sh

[Jim Meyering]

"Joel E. Denny" <[EMAIL PROTECTED]> wrote:
> Coreutils maintainers,
>
> It appears that Bison's bootstrap script is occasionally sync'ed against
> Coreutils'.  Paul Hilfinger, one of the Bison developers, recently made
> the discovery quoted below, which I figure might also be relevant to
> Coreutils.
>
> On Fri, 4 Apr 2008, Joel E. Denny wrote:
>
>> On Wed, 26 Mar 2008, Paul Hilfinger wrote:
>>
>> > The bootstrap file is headed
>> >
>> > #! /bin/sh
>> >
>> > However, it contains lines such as
>> >
>> >  if ! "$SHA1SUM" -c --status "$cksum_file" < "$new_po" >  /dev/null; 
>> > then
>> >
>> > and
>> >
>> >  if ! test -d "$dst_dir"; then
>> >
>> > In a standard Solaris 10 installation, /bin/sh does not recognize the
>> > '!' command.  I had to fix this by changing the shell used by
>> > bootstrap to /bin/bash.
>>
>> Thanks for the report.  I don't know whether Bison should switch to
>> /bin/bash or just weed out Bash-specific code.
>
> I just checked the Coreutils git repository, and it appears that similar
> constructs are still present in its latest bootstrap version.  I don't
> know whether there are other Bash-specific constructs present.
>
> It appears that Coreutils, like Bison, requires repository users to
> install Autotools, Gettext, etc, so it's probably not too much to ask them
> to install Bash as well.  However, it's not clear to me if we should
> assume Bash can then be found at /bin/bash.  What do you think?

Hi Joel,

Thanks for forwarding that.
My first reflex was to "fix" bootstrap not to use that construct,
but there are too many occurrences, and that's a slippery slope.
Besides, it's easy to work around.

I'll probably change the instructions in README-hacking to mention
that you may have to run "bash ./bootstrap" rather than

$ ./bootstrap

if your system's /bin/sh is substandard.
Plus, maybe be a test to detect the broken shell and to warn you
that you need to invoke the script differently.

An alternative is to encumber bootstrap with shell-selection
code and make it re-exec itself using a sufficiently functional shell.
But that too may fail, so I don't see the point.


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

Re: Bash vs. sh

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Jim Meyering on 4/22/2008 3:42 AM:
| I'll probably change the instructions in README-hacking to mention
| that you may have to run "bash ./bootstrap" rather than
|
|   $ ./bootstrap
|
| if your system's /bin/sh is substandard.

Sounds reasonable, since there are already a number of other hacking
instructions to follow.

| Plus, maybe be a test to detect the broken shell and to warn you
| that you need to invoke the script differently.

Absolutely; autoconf does a good job at this (and you can use the
resulting configure or config.status to get a good idea of what the code
should look like).

|
| An alternative is to encumber bootstrap with shell-selection
| code and make it re-exec itself using a sufficiently functional shell.
| But that too may fail, so I don't see the point.

Is it worth writing bootstrap.m4sh, and running it through autom4te to get
the shell selection code from autoconf with minimal effort on your part?
You'd still probably want to check in the generated bootstrap script, though.

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

iEYEARECAAYFAkgN1acACgkQ84KuGfSFAYBC5gCgie6PCrG6Wr/ksBpDNievIJWm
MXoAnijLwMPoI8FtG1I1o6/iB6kWJB4Y
=NGZA
-END PGP SIGNATURE-


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

Re: Bash vs. sh

[Jim Meyering]

Eric Blake <[EMAIL PROTECTED]> wrote:

> According to Jim Meyering on 4/22/2008 3:42 AM:
> | I'll probably change the instructions in README-hacking to mention
> | that you may have to run "bash ./bootstrap" rather than
> |
> | $ ./bootstrap
> |
> | if your system's /bin/sh is substandard.
>
> Sounds reasonable, since there are already a number of other hacking
> instructions to follow.
>
> | Plus, maybe be a test to detect the broken shell and to warn you
> | that you need to invoke the script differently.
>
> Absolutely; autoconf does a good job at this (and you can use the
> resulting configure or config.status to get a good idea of what the code
> should look like).
>
> | An alternative is to encumber bootstrap with shell-selection
> | code and make it re-exec itself using a sufficiently functional shell.
> | But that too may fail, so I don't see the point.
>
> Is it worth writing bootstrap.m4sh, and running it through autom4te to get
> the shell selection code from autoconf with minimal effort on your part?
> You'd still probably want to check in the generated bootstrap script, though.

That's tempting -- and maybe better in a way -- but not enough
to outweigh the penalty of checking in the generated code.


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

retaining AFS-specific nameless group IDs (PAG) in `id' and `groups'

[Jim Meyering]

Jim Meyering <[EMAIL PROTECTED]> wrote:
> Didi <[EMAIL PROTECTED]> wrote:
>>>  If by "unknown" you mean nameless, that's not what the patch does.
>>>  Such a patch would not even have been considered.
>>
>> I agree that hiding this information in some cases might not be
>> optimal, but the main problem is that through this the 'groups'
>> command becomes utterly useless and confused quite a lot of users.
>> $ groups
>> users id: cannot find name for group ID 1091323188
>> 1091323188
>>
>> further
>>
>> $ id -Gn
>> users id: cannot find name for group ID 1091323188
>> 1091323188
>
> If someone can provide code to determine efficiently
> whether a nameless GID is a PAG then we can probably
> make everyone happy.  If that happens, I'll need to
> know if there's a standard or accepted mapping from
> GID to PAG group name.  Pointers to unencumbered code
> would be welcome.

Since you guys are interested in AFS, I'm hoping one of you will
respond to the above.  I'll wait a few days, after which, if I don't
hear anything, I'll just revert to the old behavior.

Ideally, someone would write a patch (just outlining it is better
if you haven't already sent in FSF copyright paperwork for coreutils)
to fake a group name for a nameless group ID that is a PAG.

A hint for the ambitious: Davor Ocelic suggested that
libnss-afs already does at least some of this...


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

FYI: 3 small patches

[Jim Meyering]

FYI, here are 3 changes I've just pushed:

Accommodate building on OS/2 (www.ecomstation.com Ecs v2 rc4)
* configure.ac: Filter out carriage returns in more places.
Reported by Elbert Pol, details here:
http://thread.gmane.org/gmane.org.fsf.announce/867/focus=13332

guard against inserting a NEWS entry into a block for a prior release
Without a guard like this, it is far too easy to apply a patch
prepared against a preceding release, and not notice that a NEWS
entry is inserted into the wrong block.
* maint.mk (sc_immutable_NEWS): New rule.
(update-NEWS-hash): New rule to update the hard-coded hash.

tests: ensure that all exec-$PERL lines are the same
* maint.mk (sc_perl_coreutils_test): New rule.

>From 79a98d9bc1ee67dadc8df376d336c4f1270c464d Mon Sep 17 00:00:00 2001
From: Jim Meyering <[EMAIL PROTECTED]>
Date: Tue, 22 Apr 2008 09:33:25 +0200
Subject: [PATCH] tests: ensure that all exec-$PERL lines are the same

* maint.mk (sc_perl_coreutils_test): New rule.

Signed-off-by: Jim Meyering <[EMAIL PROTECTED]>
---
 maint.mk |   18 ++
 1 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/maint.mk b/maint.mk
index 586596b..46bc8b6 100644
--- a/maint.mk
+++ b/maint.mk
@@ -407,6 +407,24 @@ sc_GPL_version:
@grep -n 'either ''version [^3]' $$($(VC_LIST_EXCEPT)) &&   \
  { echo '$(ME): GPL vN, N!=3' 1>&2; exit 1; } || :

+exec_perl_re = \
+  exec \$$PERL -w -I\$$top_srcdir/tests -MCoreutils \
+-M"CuTmpdir qw(\$$me)" -- - <<\\EOF
+# Ensure that each test invoking $PERL with -MCoreutils uses the same line.
+sc_perl_coreutils_test:
+   @if test -f $(srcdir)/tests/Coreutils.pm; then  \
+ die=0;\
+ for i in $$(grep -l '^exec  *\$$PERL.*MCoreutils' \
+   $$($(VC_LIST) tests)); do   \
+   grep '$(exec_perl_re)' $$i > /dev/null  \
+ && : || { die=1; echo $$i; }  \
+ done; \
+ test $$die = 1 && \
+   { echo 1>&2 '$(ME): each of the above execs PERL differently:'; \
+ echo 1>&2 '(exit $$fail); exit $$fail';   \
+ exit 1; } || :;   \
+   fi
+
 # Ensure that the c99-to-c89 patch applies cleanly.
 patch-check:
rm -rf src-c89 [EMAIL PROTECTED] [EMAIL PROTECTED]
--
1.5.5.1.68.gbdcd8


>From 68466d44b1ff35383271930c12186b3d2fd53976 Mon Sep 17 00:00:00 2001
From: Jim Meyering <[EMAIL PROTECTED]>
Date: Tue, 22 Apr 2008 10:45:21 +0200
Subject: [PATCH] guard against inserting a NEWS entry into a block for a prior 
release

Without a guard like this, it is far too easy to apply a patch
prepared against a preceding release, and not notice that a NEWS
entry is inserted into the wrong block.
* maint.mk (sc_immutable_NEWS): New rule.
(update-NEWS-hash): New rule to update the hard-coded hash.

Signed-off-by: Jim Meyering <[EMAIL PROTECTED]>
---
 maint.mk |   17 +
 1 files changed, 17 insertions(+), 0 deletions(-)

diff --git a/maint.mk b/maint.mk
index 46bc8b6..e2a8e1c 100644
--- a/maint.mk
+++ b/maint.mk
@@ -42,6 +42,7 @@ endif

 PREV_VERSION := $(shell cat $(prev_version_file))
 VERSION_REGEXP = $(subst .,\.,$(VERSION))
+PREV_VERSION_REGEXP = $(subst .,\.,$(PREV_VERSION))

 ifeq ($(VC),$(GIT))
 this-vc-tag = v$(VERSION)
@@ -425,6 +426,22 @@ sc_perl_coreutils_test:
  exit 1; } || :;   \
fi

+NEWS_hash = \
+  $$(sed -n '/^\*.* $(PREV_VERSION_REGEXP) ([0-9-]*)/,$$p' \
+ $(srcdir)/NEWS | md5sum -)
+
+# Ensure that we don't accidentally insert an entry into an old NEWS block.
+old_NEWS_hash = c58d611d93d218181ed77f81ff2395ff  -
+sc_immutable_NEWS:
+   @if test -f $(srcdir)/NEWS; then\
+ test "$(NEWS_hash)" = '$(old_NEWS_hash)' && : ||  \
+   { echo '$(ME): you have modified old NEWS' 1>&2; exit 1; }; \
+   fi
+
+# Update the hash stored above.  Do this after each release.
+update-NEWS-hash: NEWS
+   perl -pi -e 's/^(old_NEWS_hash = ).*/$${1}'"$(NEWS_hash)/" $(ME)
+
 # Ensure that the c99-to-c89 patch applies cleanly.
 patch-check:
rm -rf src-c89 [EMAIL PROTECTED] [EMAIL PROTECTED]
--
1.5.5.1.68.gbdcd8


>From 0bc8813b1e40435ced17c555149e26c5aadbdda6 Mon Sep 17 00:00:00 2001
From: Jim Meyering <[EMAIL PROTECTED]>
Date: Tue, 22 Apr 2008 10:52:37 +0200
Subject: [PATCH] Accommodate building on OS/2 (www.ecomstation.com Ecs v2 rc4)

* configure.ac: Filter out carriage returns in more places.
Reported by Elbert Pol, details here:
http://thread.gmane.org/gmane.org.fsf.announce/867/focus=13332

Signed-off-by: Jim Meyering <[EMAI

[PATCH] id should not show selinux context when user is specified

[Ondřej Vašík]

Hello,
when using id  SELinux context of the user who executed id
command is printed. This is quiet misleading and should be avoided.
Problem reported in RH bugzilla #443485 by Ronny Buchmann
([EMAIL PROTECTED]) 

Patch changing the id behaviour to "don't show scontext when
user is specified" is attached.

Greetings,
 Ondrej Vasik

From b12554c8d2738385543ea7f8304a6b83ee5661b7 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Ond=C5=99ej=20Va=C5=A1=C3=ADk?= <[EMAIL PROTECTED]>
Date: Tue, 22 Apr 2008 15:37:13 +0200
Subject: [PATCH] id will now show selinux context only when used without specified user

Signed-off-by: Ondřej Vašík <[EMAIL PROTECTED]>
---
 NEWS |4 
 src/id.c |7 +--
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/NEWS b/NEWS
index 04893c6..ef3feda 100644
--- a/NEWS
+++ b/NEWS
@@ -75,6 +75,10 @@ GNU coreutils NEWS-*- outline -*-
   id and groups work around an AFS-related bug whereby those programs
   would print an invalid group number, when given no user-name argument.
 
+  id will now show selinux context only when used without specified
+  user. Showing SELinux context of user who executed id command could 
+  be misleading.
+
   ls --color no longer outputs unnecessary escape sequences
 
   seq gives better diagnostics for invalid formats.
diff --git a/src/id.c b/src/id.c
index a178714..621f2f9 100644
--- a/src/id.c
+++ b/src/id.c
@@ -48,6 +48,9 @@ char *program_name;
 /* If true, output user/group name instead of ID number. -n */
 static bool use_name = false;
 
+/* If true, id is used on specified user/group name */
+static bool specified_name = false;
+
 /* The real and effective IDs of the user to print. */
 static uid_t ruid, euid;
 static gid_t rgid, egid;
@@ -170,7 +173,7 @@ main (int argc, char **argv)
   usage (EXIT_FAILURE);
 }
 
-  if (argc - optind == 1 && just_context)
+  if ((specified_name = (argc - optind == 1)) && just_context)
 error (EXIT_FAILURE, 0,
 	   _("cannot print security context when user specified"));
 
@@ -338,6 +341,6 @@ print_full_info (const char *username)
 free (groups);
   }
 #endif /* HAVE_GETGROUPS */
-  if (context != NULL)
+  if (!specified_name && context != NULL)
 printf (" context=%s", context);
 }
-- 
1.5.2.2



signature.asc
Description: Toto je digitálně	 podepsaná část	 zprávy
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: [PATCH] md5sum+sha*sum: add option --quiet/-q to suppress OK messages

[Jim Meyering]

Erik Auerswald <[EMAIL PROTECTED]> wrote:
> IMHO md5sum and sha*sum are too verbose by default, especially when
> checking a large collection of files with only a few failing validation.
> Therefore I'd like to see an option added to suppress just the output
> for successfully verified files.
>
> The attached patch does that by adding the option --quiet/-q, including
> documentation and a testcase.

Hi Erik,

Thank you for a fine patch.
That looks very good.
The only suggestion I can make so far is to omit the short-named "-q" option.
The "--q" abbreviation of --quiet is only one byte longer.

However, we'll need to deal with copyright paperwork
before I can apply it.  Please follow the instructions in
the file, HACKING, in the "Copyright assignment" section.

Jim

P.S., please adjust your mail client.
Currently, it emits an invalid "Mail-Followup-To:" line:

  Mail-Followup-To: auerswal, bug-coreutils@gnu.org


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

Re: [PATCH] id should not show selinux context when user is specified

[Jim Meyering]

Ondřej Vašík <[EMAIL PROTECTED]> wrote:
...
> +/* If true, id is used on specified user/group name */
> +static bool specified_name = false;
> +
>  /* The real and effective IDs of the user to print. */
>  static uid_t ruid, euid;
>  static gid_t rgid, egid;
> @@ -170,7 +173,7 @@ main (int argc, char **argv)
>usage (EXIT_FAILURE);
>  }
>
> -  if (argc - optind == 1 && just_context)
> +  if ((specified_name = (argc - optind == 1)) && just_context)
>  error (EXIT_FAILURE, 0,
>  _("cannot print security context when user specified"));
>
> @@ -338,6 +341,6 @@ print_full_info (const char *username)
>  free (groups);
>}
>  #endif /* HAVE_GETGROUPS */
> -  if (context != NULL)
> +  if (!specified_name && context != NULL)
>  printf (" context=%s", context);

Hi Ondřej,

Thank you for the patch.
Please change it so specified_name is local to main
and then just use it to avoid calling getcon.

Actually, I think this tiny change is enough:

-  if (selinux_enabled)
+  if (selinux_enabled && argc == optind)

...assuming you update the comment above that.

Also, for fixes like this, a new test case is required.
Do you feel like writing that?


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

Re: [PATCH] md5sum+sha*sum: add option --quiet/-q to suppress OK messages

[Erik Auerswald]

Hi,

On Tue, Apr 22, 2008 at 06:05:48PM +0200, Jim Meyering wrote:
> Erik Auerswald <[EMAIL PROTECTED]> wrote:
> > IMHO md5sum and sha*sum are too verbose by default, especially when
> > checking a large collection of files with only a few failing validation.
> > Therefore I'd like to see an option added to suppress just the output
> > for successfully verified files.
> >
> > The attached patch does that by adding the option --quiet/-q, including
> > documentation and a testcase.
> 
> Thank you for a fine patch.
> That looks very good.
> The only suggestion I can make so far is to omit the short-named "-q" option.
> The "--q" abbreviation of --quiet is only one byte longer.

The short "-q" is commonly used for "--quiet", I would expect it's
existence for every progam having short option names and this kind of
functionality.

If you insist on omitting it I'll remove it from the next version of the
patch, but I'd prefer it with "-q".

> However, we'll need to deal with copyright paperwork
> before I can apply it.  Please follow the instructions in
> the file, HACKING, in the "Copyright assignment" section.

I'll see to this.

> P.S., please adjust your mail client.
> Currently, it emits an invalid "Mail-Followup-To:" line:
> 
>   Mail-Followup-To: auerswal, bug-coreutils@gnu.org

Sorry, should be fixed.

Erik


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

Re: [PATCH] md5sum+sha*sum: add option --quiet/-q to suppress OK messages

[Jim Meyering]

Erik Auerswald <[EMAIL PROTECTED]> wrote:
> On Tue, Apr 22, 2008 at 06:05:48PM +0200, Jim Meyering wrote:
>> Erik Auerswald <[EMAIL PROTECTED]> wrote:
>> > IMHO md5sum and sha*sum are too verbose by default, especially when
>> > checking a large collection of files with only a few failing validation.
>> > Therefore I'd like to see an option added to suppress just the output
>> > for successfully verified files.
>> >
>> > The attached patch does that by adding the option --quiet/-q, including
>> > documentation and a testcase.
>>
>> Thank you for a fine patch.
>> That looks very good.
>> The only suggestion I can make so far is to omit the short-named "-q" option.
>> The "--q" abbreviation of --quiet is only one byte longer.
>
> The short "-q" is commonly used for "--quiet", I would expect it's
> existence for every progam having short option names and this kind of
> functionality.
>
> If you insist on omitting it I'll remove it from the next version of the
> patch, but I'd prefer it with "-q".

Sorry, but I do insist.

It's not an arbitrary decision, and I'm not picking on you in particular.
Everyone who proposes to add short-named options to existing programs
gets the same answer.

This is a hard and fast policy in coreutils:
No new short options, unless you somehow manage
to prove that it won't ever conflict with some
other vendor's -q option.  And even then, I'd
probably reject it, unless it's somehow standardized.


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

Re: [PATCH] Use a hash rather than a linked-list for cycle check in cp

[James Youngman]

On Wed, Apr 16, 2008 at 10:34 PM, Bo Borgerson <[EMAIL PROTECTED]> wrote:
>  The performance benefit is there, but on my machine with a PATH_MAX of
>  4096 it's hard to see, because the userland work `cp' does is dwarfed
>  by the work the kernel does on its behalf:

Many platforms allow you to create a directory tree whose
fully-specified components are much longer than PATH_MAX, as long as
you don't try to create/delete/traverse them by their fully-qualified
name. This included Linux and HP-UX when I tried it (in about
1995, so things may have changed).

James.


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

Re: coreutils-6.11 released

[Christophe LYON]

On 19.04.2008 23:21, Jim Meyering wrote:

Coreutils version 6.11 has been released.  This is a stable release.



Hello,

My build fails on a Solaris 8 machine, using gcc-4.1.0.
When building "sort", I get:

.../gcc -std=gnu99  -O2 -Wl,--as-needed -o sort sort.o 
../lib/libcoreutils.a  ../lib/libcoreutils.a   -lsocket

../lib/libcoreutils.a(strtod.o): In function `rpl_strtod':
strtod.c:(.text+0x18c): undefined reference to `pow'
strtod.c:(.text+0x634): undefined reference to `pow'
strtod.c:(.text+0x6a4): undefined reference to `pow'
collect2: ld returned 1 exit status


If I manually add "-lm", I get:
.../bin/../lib/gcc/sparc-sun-solaris2.8/4.1.0/crt1.o:(.plt+0x0): 
multiple definition of `_PROCEDURE_LINKAGE_TABLE_'

/usr/lib/libm.so:(.plt+0x0): first defined here

Is this a supported host?

Regards,

Christophe.


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

ls --color=tty

[tiger peng]

Hello, 

Yesterday, I modified a shell script and some how it became non-executable 
(-rw-r--r--) but it is still list in green color. I did not notice the 
permission change until this morning when my cron jobs failed. I can not 
reproduce this scenario 

OS: Linux 2.4.21-27.ELsmp
Term: PuTTY XTERM
ls --version: (coreutils) 4.5.3
ls='ls --color=tty'

Have anyone run into this problem? 

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

md5sum is sensitive to line terminator of md5 file

[John Blythe]

Hi, I have just noticed that checking md5 hashes in an correctly formated  
md5 file fails on linux if the file

has crlf line terminators.

It gives unhelpful and incorrectly formatted errors messages such as,

#line in checksums.md5
8a107f691b48ffe203938be1ed6cdbe7 *04 - Totnes Bickering Fair.mp3

#error message output
: No such file or directoryng Fair.mp3
: FAILED open or read Fair.mp3
: No such file or directory3


Changing line terminators with a utility such as dos2unix fixes the  
problem. I cannot say if the opposite problem exists on DOS based systems.


Wouldn't it be better to detect and take into account the
line terminators possiblly with a warning?

Cheers - John Blythe.

--

In girum imus nocte et consumimur igni.


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

Re: PATH and security

[James Youngman]

Well, more generally I like the fact that changing the value of $PWD
doesn't modify the meaning of programs.

James.


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

Re: [PATCH] Use a hash rather than a linked-list for cycle check in cp

[Jim Meyering]

"Bo Borgerson" <[EMAIL PROTECTED]> wrote:
> This addresses a FIXME in src/copy.c:
>
> 
> -/* FIXME: rewrite this to use a hash table so we avoid the quadratic
> -   performance hit that's probably noticeable only on trees deeper
> -   than a few hundred levels.  See use of active_dir_map in remove.c  */
> 
>
> The performance benefit is there, but on my machine with a PATH_MAX of
> 4096 it's hard to see, because the userland work `cp' does is dwarfed
> by the work the kernel does on its behalf:
>
> 
> $ time src/cp.master -r a b
>
> real0m54.032s
> user0m3.236s<-- coreutils HEAD
> sys 0m47.335s
>
> $ time src/cp -r a c
>
> real0m53.475s
> user0m0.624s<-- with patch
> sys 0m48.639s
> 

Hi Bo,

Thanks for that patch.

However, let's see if Cai Xianchao and Li Zefan
are still working on rewriting cp to use openat-style functions.

  http://thread.gmane.org/gmane.comp.gnu.coreutils.bugs/12041

Because once cp is rewritten the way I outlined later in
that thread, there will be no need for your patch.

By the way, I do still plan to add a --total option to df.
Li Zefan revived an old patch to that effect, but it needs
some work and perhaps a test or two.


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

Re: FYI: 3 small patches

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Jim Meyering on 4/22/2008 8:28 AM:
| Without a guard like this, it is far too easy to apply a patch
| prepared against a preceding release, and not notice that a NEWS
| entry is inserted into the wrong block.
| * maint.mk (sc_immutable_NEWS): New rule.
| (update-NEWS-hash): New rule to update the hard-coded hash.
|
| +
| +# Ensure that we don't accidentally insert an entry into an old NEWS block.
| +old_NEWS_hash = c58d611d93d218181ed77f81ff2395ff  -
| +sc_immutable_NEWS:
| + @if test -f $(srcdir)/NEWS; then\
| +   test "$(NEWS_hash)" = '$(old_NEWS_hash)' && : ||\
| + { echo '$(ME): you have modified old NEWS' 1>&2; exit 1; };  \
| + fi
| +
| +# Update the hash stored above.  Do this after each release.
| +update-NEWS-hash: NEWS
| + perl -pi -e 's/^(old_NEWS_hash = ).*/$${1}'"$(NEWS_hash)/" $(ME)

Nice rule.  However, two concerns here.  First, how do you intend to share
maint.mk with other projects, when the NEWS hash to coreutils is now
hardcoded in here?  Shouldn't the hash be stored in cfg.mk instead?
Second, what happens if a typo correction is made in the old NEWS?  I
guess that means manually updating the hash to account for the intentional
changes (or maybe running 'make update-NEWS-hash' after ensuring that all
I changed was a typo fix).

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

iEYEARECAAYFAkgON9gACgkQ84KuGfSFAYAKpACgqpuTcXZ7SWfyAl+jy8Z8qR3X
FR4An00Ru5c4IQU19wxqX6Df0Xov63Vo
=d8FX
-END PGP SIGNATURE-


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

Re: Bash vs. sh

[Jim Meyering]

Eric Blake <[EMAIL PROTECTED]> wrote:

> According to Jim Meyering on 4/22/2008 7:23 AM:
> |> Is it worth writing bootstrap.m4sh, and running it through autom4te to get
> |> the shell selection code from autoconf with minimal effort on your part?
> |> You'd still probably want to check in the generated bootstrap script,
> though.
> |
> | That's tempting -- and maybe better in a way -- but not enough
> | to outweigh the penalty of checking in the generated code.
>
> But since an installed autoconf is a prerequisite to running bootstrap,
> maybe you could document:
>
> $ git clone ...
> $ cd coreutils
> $ autom4te --language=m4sh bootstrap.m4sh -o bootstrap
> $ ./bootstrap
> $ ./configure
> $ make
>
> as the preferred method for getting started, avoiding the need to check in
> bootstrap?  Or even have a two-level bootstrap: ./bootstrap is a simple
> checked-in wrapper which portably calls autom4te on bootstrap_inner.m4sh
> then runs bootstrap_inner with the expectation of a better shell?

Actually, I like that.
Are you interested in writing the patch?

> Oh well, I can dream :)

Thanks for persevering.


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

Re: FYI: 3 small patches

[Jim Meyering]

Eric Blake <[EMAIL PROTECTED]> wrote:
> According to Jim Meyering on 4/22/2008 8:28 AM:
> | Without a guard like this, it is far too easy to apply a patch
> | prepared against a preceding release, and not notice that a NEWS
> | entry is inserted into the wrong block.
> | * maint.mk (sc_immutable_NEWS): New rule.
> | (update-NEWS-hash): New rule to update the hard-coded hash.
> |
> | +
> | +# Ensure that we don't accidentally insert an entry into an old NEWS block.
> | +old_NEWS_hash = c58d611d93d218181ed77f81ff2395ff  -
> | +sc_immutable_NEWS:
> | +   @if test -f $(srcdir)/NEWS; then\
> | + test "$(NEWS_hash)" = '$(old_NEWS_hash)' && : ||  \
> | +   { echo '$(ME): you have modified old NEWS' 1>&2; exit 1; }; \
> | +   fi
> | +
> | +# Update the hash stored above.  Do this after each release.
> | +update-NEWS-hash: NEWS
> | +   perl -pi -e 's/^(old_NEWS_hash = ).*/$${1}'"$(NEWS_hash)/" $(ME)
>
> Nice rule.  However, two concerns here.  First, how do you intend to share
> maint.mk with other projects, when the NEWS hash to coreutils is now
> hardcoded in here?  Shouldn't the hash be stored in cfg.mk instead?

You caught me ;-).  Actually I thought of that initially, but then
forgot when implementing it.  I'll move it right away.  Thanks.

> Second, what happens if a typo correction is made in the old NEWS?  I
> guess that means manually updating the hash to account for the intentional
> changes (or maybe running 'make update-NEWS-hash' after ensuring that all
> I changed was a typo fix).

Exactly, but don't run it manually.
I'll add a comment that it's ok to run it for corrections, too.

BTW, I do want to update NEWS as you suggested re ls --colors,
but haven't done it yet.  If you already know what it should
say, I'd love a patch that would save me the time of digging
for it all over again.


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

Re: md5sum is sensitive to line terminator of md5 file

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to John Blythe on 4/22/2008 12:27 PM:
| Hi, I have just noticed that checking md5 hashes in an correctly
| formated md5 file fails on linux if the file
| has crlf line terminators.

This has been previously reported (and even some tentative patches
provided), but not yet cleanly dealt with.  A true fix would also have to
encode carriage returns as \r in the md5 output, so that files ending in
cr (on platforms that actually allow that) cannot be confused with a
change in line terminators.

It's been on my TODO list for a long time now, but never percolated to the
top.

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

iEYEARECAAYFAkgOOoIACgkQ84KuGfSFAYCYKACeInBNSj15iT+RnxOYEqC+o5Vh
PvYAoJnkBS5t9SHdisABkoCTkidWw+sP
=yLyR
-END PGP SIGNATURE-


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

Re: Bash vs. sh

[Jim Meyering]

"Joel E. Denny" <[EMAIL PROTECTED]> wrote:

> On Tue, 22 Apr 2008, Jim Meyering wrote:
>
>> > as the preferred method for getting started, avoiding the need to check in
>> > bootstrap?  Or even have a two-level bootstrap: ./bootstrap is a simple
>> > checked-in wrapper which portably calls autom4te on bootstrap_inner.m4sh
>> > then runs bootstrap_inner with the expectation of a better shell?
>>
>> Actually, I like that.
>> Are you interested in writing the patch?
>
> As long as we're discussing a two-level bootstrap
>
> How many packages are syncing their bootstrap scripts with Coreutils?
> Bison has made some changes to bootstrap that Coreutils might benefit
> from, and vice-versa.  If there are other projects besides Bison and
> Coreutils, maybe bootstrap_inner.m4sh, like GNUmakefile, should be placed
> in gnulib.  Your bootstrap wrapper would download it before running

:-)
There's already a bootstrap module in gnulib.
We sync things around periodically.
Patches welcome, of course.

> autom4te.  This wrapper will hopefully remain much simpler than
> bootstrap_inner.m4sh and rarely require syncing among projects.  Besides,
> the wrapper may be a place for project-specific bootstrap tasks that
> bootstrap_inner.m4sh doesn't handle, if any.


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

Re: [PATCH] Use a hash rather than a linked-list for cycle check in cp

[Bo Borgerson]

On Tue, Apr 22, 2008 at 3:03 PM, Jim Meyering <[EMAIL PROTECTED]> wrote:
>
>  Hi Bo,
>
>  Thanks for that patch.
>
>  However, let's see if Cai Xianchao and Li Zefan
>  are still working on rewriting cp to use openat-style functions.
>
>   http://thread.gmane.org/gmane.comp.gnu.coreutils.bugs/12041
>
>  Because once cp is rewritten the way I outlined later in
>  that thread, there will be no need for your patch.
>

Hi,

I may be missing something, but from a scan of that thread it seems to
me that the two patches are actually mutually beneficial.

My patch makes the check for cycles the directory graph cheaper, but
the limitation of PATH_MAX meant that the maximum penalty for this
check wasn't ever that significant.

If the cap on recursion imposed by PATH_MAX were to be lifted then the
performance benefit realized from a cheaper cycle check would be more
significant.

Bo


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

Re: [PATCH] Use a hash rather than a linked-list for cycle check in cp

[Jim Meyering]

"Bo Borgerson" <[EMAIL PROTECTED]> wrote:

> On Tue, Apr 22, 2008 at 3:03 PM, Jim Meyering <[EMAIL PROTECTED]> wrote:
>>
>>  Hi Bo,
>>
>>  Thanks for that patch.
>>
>>  However, let's see if Cai Xianchao and Li Zefan
>>  are still working on rewriting cp to use openat-style functions.
>>
>>   http://thread.gmane.org/gmane.comp.gnu.coreutils.bugs/12041
>>
>>  Because once cp is rewritten the way I outlined later in
>>  that thread, there will be no need for your patch.
>
> Hi,
>
> I may be missing something, but from a scan of that thread it seems to
> me that the two patches are actually mutually beneficial.

The change I want is to make cp use fts,
and fts already does efficient cycle detection.


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

Re: FYI: 3 small patches

[Jim Meyering]

Eric Blake <[EMAIL PROTECTED]> wrote:

> According to Jim Meyering on 4/22/2008 8:28 AM:
> | Without a guard like this, it is far too easy to apply a patch
> | prepared against a preceding release, and not notice that a NEWS
> | entry is inserted into the wrong block.
> | * maint.mk (sc_immutable_NEWS): New rule.
> | (update-NEWS-hash): New rule to update the hard-coded hash.
> |
> | +
> | +# Ensure that we don't accidentally insert an entry into an old NEWS block.
> | +old_NEWS_hash = c58d611d93d218181ed77f81ff2395ff  -
> | +sc_immutable_NEWS:
> | +   @if test -f $(srcdir)/NEWS; then\
> | + test "$(NEWS_hash)" = '$(old_NEWS_hash)' && : ||  \
> | +   { echo '$(ME): you have modified old NEWS' 1>&2; exit 1; }; \
> | +   fi
> | +
> | +# Update the hash stored above.  Do this after each release.
> | +update-NEWS-hash: NEWS
> | +   perl -pi -e 's/^(old_NEWS_hash = ).*/$${1}'"$(NEWS_hash)/" $(ME)
>
> Nice rule.  However, two concerns here.  First, how do you intend to share
> maint.mk with other projects, when the NEWS hash to coreutils is now
> hardcoded in here?  Shouldn't the hash be stored in cfg.mk instead?
> Second, what happens if a typo correction is made in the old NEWS?  I
> guess that means manually updating the hash to account for the intentional
> changes (or maybe running 'make update-NEWS-hash' after ensuring that all
> I changed was a typo fix).

BTW, here's what I've just pushed:

>From d9c1b8fd30a36d7f05cfb8f830dc62765cf60792 Mon Sep 17 00:00:00 2001
From: Jim Meyering <[EMAIL PROTECTED]>
Date: Tue, 22 Apr 2008 21:28:33 +0200
Subject: [PATCH] build: move a project-specific definition to cfg.mk

* cfg.mk (old_NEWS_hash): Define here, ...
* maint.mk: ... not here.
(update-NEWS-hash): Update comment.
Suggestion from Eric Blake.

Signed-off-by: Jim Meyering <[EMAIL PROTECTED]>
---
 cfg.mk   |2 ++
 maint.mk |7 ---
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/cfg.mk b/cfg.mk
index 61c3bc5..6b039c5 100644
--- a/cfg.mk
+++ b/cfg.mk
@@ -39,3 +39,5 @@ gnulib_dir = /gnulib

 # Now that we have better (check.mk) tests, make this the default.
 export VERBOSE = yes
+
+old_NEWS_hash = c58d611d93d218181ed77f81ff2395ff  -
diff --git a/maint.mk b/maint.mk
index e2a8e1c..66f6d5d 100644
--- a/maint.mk
+++ b/maint.mk
@@ -431,16 +431,17 @@ NEWS_hash = \
  $(srcdir)/NEWS | md5sum -)

 # Ensure that we don't accidentally insert an entry into an old NEWS block.
-old_NEWS_hash = c58d611d93d218181ed77f81ff2395ff  -
 sc_immutable_NEWS:
@if test -f $(srcdir)/NEWS; then\
  test "$(NEWS_hash)" = '$(old_NEWS_hash)' && : ||  \
{ echo '$(ME): you have modified old NEWS' 1>&2; exit 1; }; \
fi

-# Update the hash stored above.  Do this after each release.
+# Update the hash stored above.  Do this after each release and
+# for any corrections to old entries.
 update-NEWS-hash: NEWS
-   perl -pi -e 's/^(old_NEWS_hash = ).*/$${1}'"$(NEWS_hash)/" $(ME)
+   perl -pi -e 's/^(old_NEWS_hash = ).*/$${1}'"$(NEWS_hash)/" \
+ $(srcdir)/cfg.mk

 # Ensure that the c99-to-c89 patch applies cleanly.
 patch-check:
--
1.5.5.1.68.gbdcd8


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

[bug #23023] cp -r use a lot of memory, feature or memory leak?

[Matteo Boccafoli]

URL:
  

 Summary: cp -r use a lot of memory,  feature or memory leak?
 Project: GNU Core Utilities
Submitted by: matteo
Submitted on: martedì 22/04/2008 alle 22:13
Category: None
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Private
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

# 21000 dir in 1.tar.bz2
$ cd /dev/shm
/dev/shm$ time tar -xjf 1.tar.bz2

real0m8.403s
user0m3.188s
sys 0m5.196s

/dev/shm$ time ./busybox cp -r /dev/shm/1/ /dev/shm/b
real0m54.421s
user0m0.832s
sys 0m51.751s
# [time t_1,t_2 : t_1http://savannah.gnu.org/bugs/download.php?file_id=15507>

___

Reply to this item at:

  

___
  Messaggio inviato con/da Savannah
  http://savannah.gnu.org/



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

[PATCH] Improve memory management in join

[Bo Borgerson]

Hi,

This improves the performance of `join' by reducing memory management
overhead and eliminating unnecessary copies for order checking:

$ valgrind src/join.master ja jb
==23744== malloc/free: 4,571,152 allocs, 4,571,152 frees, 255,971,774
bytes allocated.

$ valgrind src/join ja jb
==23738== malloc/free: 1,405 allocs, 1,405 frees, 65,858 bytes allocated.

$ time src/join.master ja jb
user0m27.126s

$ time src/join ja jb
user0m17.297s

Thanks,

Bo
From 623a2f43593093b3fb8cde9472bf5ecec652b6d3 Mon Sep 17 00:00:00 2001
From: Bo Borgerson <[EMAIL PROTECTED]>
Date: Tue, 22 Apr 2008 16:19:58 -0400
Subject: [PATCH] Improve memory management in join

* src/join.c (struct seq): Use a (struct line **) for `lines' rather than
one long (struct line *).  This allows individual lines to be swapped out
if necessary.
(reset_line): Get a line ready for new input.
(init_linep): Create a new line and assign it to the the pointer passed in.
(spareline[2]): Hold a spare line for each input file.
(free_spareline): Clean up.
(get_line): Take a (struct line **) instead of a (struct line *).  If the
line to be overwritten is the previous line for the current file then swap
it out for the spare.
(join): Accomodate new structure of SEQs and new parameters to get_line;
Don't free stale lines until the end -- they're re-usable now.
(dup_line): Removed.

Signed-off-by: Bo Borgerson <[EMAIL PROTECTED]>
---
 src/join.c |  169 +++
 1 files changed, 89 insertions(+), 80 deletions(-)

diff --git a/src/join.c b/src/join.c
index b8a0011..56eabc5 100644
--- a/src/join.c
+++ b/src/join.c
@@ -40,6 +40,12 @@
 
 #define join system_join
 
+#define SWAPLINES(a, b) do { \
+  struct line *tmp = a; \
+  a = b; \
+  b = tmp; \
+} while (0);
+
 /* An element of the list identifying which fields to print for each
output line.  */
 struct outlist
@@ -76,14 +82,19 @@ struct seq
   {
 size_t count;			/* Elements used in `lines'.  */
 size_t alloc;			/* Elements allocated in `lines'.  */
-struct line *lines;
+struct line **lines;
   };
 
 /* The name this program was run with.  */
 char *program_name;
 
 /* The previous line read from each file. */
-static struct line *prevline[2];
+static struct line *prevline[2] = {NULL, NULL};
+
+/* This provides an extra line buffer for each file.  We need these if we
+   try to read two consecutive lines into the same buffer, since we don't
+   want to overwrite the previous buffer before we check order. */
+static struct line *spareline[2] = {NULL, NULL};
 
 /* True if the LC_COLLATE locale is hard.  */
 static bool hard_LC_COLLATE;
@@ -260,33 +271,6 @@ xfields (struct line *line)
   extract_field (line, ptr, lim - ptr);
 }
 
-static struct line *
-dup_line (const struct line *old)
-{
-  struct line *newline = xmalloc (sizeof *newline);
-  size_t i;
-
-  /* Duplicate the buffer. */
-  initbuffer (&newline->buf);
-  newline->buf.buffer = xmalloc (old->buf.size);
-  newline->buf.size = old->buf.size;
-  memcpy (newline->buf.buffer, old->buf.buffer, old->buf.length);
-  newline->buf.length = old->buf.length;
-
-  /* Duplicate the field positions. */
-  newline->fields = xnmalloc (old->nfields_allocated, sizeof *newline->fields);
-  newline->nfields = old->nfields;
-  newline->nfields_allocated = old->nfields_allocated;
-
-  for (i = 0; i < old->nfields; i++)
-{
-  newline->fields[i].len = old->fields[i].len;
-  newline->fields[i].beg = newline->buf.buffer + (old->fields[i].beg
-		  - old->buf.buffer);
-}
-  return newline;
-}
-
 static void
 freeline (struct line *line)
 {
@@ -393,49 +377,69 @@ check_order (const struct line *prev,
 }
 }
 
+static inline void
+reset_line (struct line *line)
+{
+  line->nfields = 0;
+}
+
+static struct line *
+init_linep (struct line **linep)
+{
+  struct line *line = xmalloc (sizeof *line);
+  memset (line, '\0', sizeof *line);
+  *linep = line;
+  return line;
+}
+
 /* Read a line from FP into LINE and split it into fields.
Return true if successful.  */
 
 static bool
-get_line (FILE *fp, struct line *line, int which)
+get_line (FILE *fp, struct line **linep, int which)
 {
-  initbuffer (&line->buf);
+  struct line *line = *linep;
+
+  if (line == prevline[which - 1])
+{
+  SWAPLINES (line, spareline[which - 1]);
+  *linep = line;
+}
+
+  if (line)
+reset_line (line);
+  else
+line = init_linep (linep);
 
   if (! readlinebuffer (&line->buf, fp))
 {
   if (ferror (fp))
 	error (EXIT_FAILURE, errno, _("read error"));
-  free (line->buf.buffer);
-  line->buf.buffer = NULL;
+  freeline (line);
   return false;
 }
 
-  line->nfields_allocated = 0;
-  line->nfields = 0;
-  line->fields = NULL;
   xfields (line);
 
   if (prevline[which - 1])
-{
-  check_order (prevline[which - 1], line, which);
-  freeline (prevline[which - 1]);
-  free (prevline[which - 1]);
-}
-  prevline[which - 1] = dup_line (line);

Re: [PATCH] Improve memory management in join

[Jim Meyering]

"Bo Borgerson" <[EMAIL PROTECTED]> wrote:
> This improves the performance of `join' by reducing memory management
> overhead and eliminating unnecessary copies for order checking:
>
> $ valgrind src/join.master ja jb
> ==23744== malloc/free: 4,571,152 allocs, 4,571,152 frees, 255,971,774
> bytes allocated.
>
> $ valgrind src/join ja jb
> ==23738== malloc/free: 1,405 allocs, 1,405 frees, 65,858 bytes allocated.
>
> $ time src/join.master ja jb
> user0m27.126s
>
> $ time src/join ja jb
> user0m17.297s

Oooh.  That's nice.
Hard to argue with such results.

What do you think about making the above into coreutils' first
performance-measuring test?
It would run only if valgrind is available, sizeof void* == N
(for whatever N is on some type of system), and that would fail
if the total number of bytes allocates is larger than say, 7?

I'll look at the patch itself in the next few days.

> Subject: [PATCH] Improve memory management in join
>
> * src/join.c (struct seq): Use a (struct line **) for `lines' rather than
> one long (struct line *).  This allows individual lines to be swapped out
> if necessary.
> (reset_line): Get a line ready for new input.
> (init_linep): Create a new line and assign it to the the pointer passed in.
> (spareline[2]): Hold a spare line for each input file.
> (free_spareline): Clean up.
> (get_line): Take a (struct line **) instead of a (struct line *).  If the
> line to be overwritten is the previous line for the current file then swap
> it out for the spare.
> (join): Accomodate new structure of SEQs and new parameters to get_line;
> Don't free stale lines until the end -- they're re-usable now.
> (dup_line): Removed.


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

Re: coreutils-6.11 released

[Jim Meyering]

Elbert Pol <[EMAIL PROTECTED]> wrote:
> I try that build, but is fails now at a earlyer point.

Well, your logs show that configure succeeded, which means the
failure is _later_.  And that means my patch solved the problem.

> I attach logs

Thank you.
The first interesting part is here:

In file included from file-set.h:2,
 from file-set.c:20:
sys/stat.h:267:8: operator '!' has no right operand
make.exe[3]: *** [file-set.o] Error 1

That suggests that HAVE_LSTAT is not expanded as expected in
lib/sys/stat.h.  The template, lib/sys_stat.in.h has this:

#if ! @HAVE_LSTAT@
# define lstat stat
#endif

yet, the diagnostic above suggests your lib/sys/stat.h looks like this:

#if !
# define lstat stat
#endif

Contrast that with your config.log file, which says

#define HAVE_LSTAT 1

So, would you please post both your lib/sys/stat.h,
to confirm, and config.status, since it is the file
responsible for performing the substitution that may be failing.


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

Re: PATH and security

[Jim Meyering]

Bruno Haible <[EMAIL PROTECTED]> wrote:

> Jim Meyering wrote:
>> If security isn't enough of an argument, you can consider this yet another
>> reason not to put "." early in your PATH.  Please consider removing
>> "." from your PATH altogether.  Yes, that does make for some small amount
>> of extra typing (you have to prefix certain commands with "./"), but
>> that is a small price to pay for the reduced risk of mishap.
>> [Sorry to harp on this again, but I wouldn't want readers to get the
>>  impression that it's ok to have "." *anywhere* in PATH, much less
>>  near the beginning. ]
>
> The only security argument I've seen so far against "." in PATH is that
> every user, at some point in time, does things like
>   $ cd /tmp
>   $ ls -l
> and another user on the same machine may have stored a malicious program
> at /tmp/ls.
>
> A similar argument holds for group-writable directories on machines where
> you don't trust all users of the same group.
>
> But when you are on a LAN where you trust all users, or on a firewalled
> machine where you are the only user and even your own sysadmin, I see no
> point in reducing the PATH. - If you trust everyone in your house, and have
> a lock at the door of your house, would you also lock your bedroom's door
> at night?

Habits are habits.
If I acquire habits that are safe only in a few
protected environments, what's to prevent that often-safe
behavior from leaking into an environment where it's no longer safe?
I prefer to maintain safe habits.

Besides, I recognize that no system is immune from risk.
I.e., a bug in my browser may allow malicious code to create
that /tmp/ls file you mentioned.


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

Re: Bash vs. sh

[Joel E. Denny]

On Tue, 22 Apr 2008, Jim Meyering wrote:

> > as the preferred method for getting started, avoiding the need to check in
> > bootstrap?  Or even have a two-level bootstrap: ./bootstrap is a simple
> > checked-in wrapper which portably calls autom4te on bootstrap_inner.m4sh
> > then runs bootstrap_inner with the expectation of a better shell?
> 
> Actually, I like that.
> Are you interested in writing the patch?

As long as we're discussing a two-level bootstrap

How many packages are syncing their bootstrap scripts with Coreutils?  
Bison has made some changes to bootstrap that Coreutils might benefit 
from, and vice-versa.  If there are other projects besides Bison and 
Coreutils, maybe bootstrap_inner.m4sh, like GNUmakefile, should be placed 
in gnulib.  Your bootstrap wrapper would download it before running 
autom4te.  This wrapper will hopefully remain much simpler than 
bootstrap_inner.m4sh and rarely require syncing among projects.  Besides, 
the wrapper may be a place for project-specific bootstrap tasks that 
bootstrap_inner.m4sh doesn't handle, if any.


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

Re: retaining AFS-specific nameless group IDs (PAG) in `id' and `groups'

[Adam Megacz]

Jim Meyering <[EMAIL PROTECTED]> writes:
> Since you guys are interested in AFS, I'm hoping one of you will
> respond to the above.

http://lists.openafs.org/pipermail/openafs-info/2008-April/029132.html

> I'll wait a few days, after which, if I don't hear anything, I'll
> just revert to the old behavior.

If "old behavior" means no special action for GIDs that might be PAGs,
I think that is the right course of action.

  - a



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

cp: preserve existing destination file

[HarriKa]

Hello,

thanks for providing the GNU-system coreutils.

Unfortunately, after a new system installation, I just today discovered, that 
the --reply=foo option in cp has been deprecated and is going to be removed.

I often want to do "cp dir1/* dir2", but protect the files already existing in 
dir2 from being overwritten by the older files from dir1.
I could use "-u", but I often deal with files, on whose timestamps I cannot 
safely rely on.
How to do this without "-i --reply=no"? Or is there anything I overlooked? Hope 
not.

Best regards,

Harald Katzer
-- 
Pt! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger


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

Re: Bash vs. sh

[Joel E. Denny]

On Tue, 22 Apr 2008, Jim Meyering wrote:

> "Joel E. Denny" <[EMAIL PROTECTED]> wrote:

> There's already a bootstrap module in gnulib.

You mean build-aux/bootstrap?

> We sync things around periodically.

I was hoping for something more formal: all developers commit their 
bootstrap-inner.m4sh changes to gnulib instead of to their own projects.  
Writing bootstrap to download bootstrap-inner.m4sh automatically might 
help encourage this practice.  Then I don't have to hunt through the logs 
of several other projects in order to avoid reinventing bootstrapping 
fixes.

> Patches welcome, of course.

I'll wait at least until after Eric's two-stage bootstrap is ready.  
Maybe someone will beat me to it.

Thanks for your responses.


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

Re: cp: preserve existing destination file

[Bob Proulx]

[EMAIL PROTECTED] wrote:
> Unfortunately, after a new system installation, I just today
> discovered, that the --reply=foo option in cp has been deprecated
> and is going to be removed.

Yes.  It didn't do what people thought it did.  It was possible to
have silent data loss.

> I often want to do "cp dir1/* dir2", but protect the files already
> existing in dir2 from being overwritten by the older files from
> dir1.  I could use "-u", but I often deal with files, on whose
> timestamps I cannot safely rely on.  How to do this without "-i
> --reply=no"? Or is there anything I overlooked? Hope not.

Use rsync for this functionality.

  $ rsync -a --ignore-existing file1 file2

See this reference for more information:

  
http://www.gnu.org/software/coreutils/faq/#cp-and-mv-the-reply-option-is-deprecated

Bob


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

Re: PATH and security

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Jim Meyering on 4/22/2008 5:13 PM:
|>> If security isn't enough of an argument, you can consider this yet another
|>> reason not to put "." early in your PATH.  Please consider removing
|>> "." from your PATH altogether.

|
| Besides, I recognize that no system is immune from risk.
| I.e., a bug in my browser may allow malicious code to create
| that /tmp/ls file you mentioned.

I personally like having . in my PATH on systems I manage, but only at the
end and never first, so I can guarantee that any important program (like
/bin/ls) cannot be inadvertently replaced by a malicious /tmp/ls.

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

iEYEARECAAYFAkgOwroACgkQ84KuGfSFAYANfACgn04WGKCqJ+shKYcKvvbFc8X/
txgAn3JTJWtntANLifoj2gKzhWsqyBwU
=Nu2/
-END PGP SIGNATURE-


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

Re: Bash vs. sh

[Jim Meyering]

"Joel E. Denny" <[EMAIL PROTECTED]> wrote:
> On Tue, 22 Apr 2008, Jim Meyering wrote:
>
>> "Joel E. Denny" <[EMAIL PROTECTED]> wrote:
>
>> There's already a bootstrap module in gnulib.
>
> You mean build-aux/bootstrap?

Yes.

>> We sync things around periodically.
>
> I was hoping for something more formal: all developers commit their
> bootstrap-inner.m4sh changes to gnulib instead of to their own projects.

That's already the idea, using gnulib's bootstrap.
And things are in sync, modulo a few kludges I've
had to add for coreutils.

> Writing bootstrap to download bootstrap-inner.m4sh automatically might
> help encourage this practice.  Then I don't have to hunt through the logs
> of several other projects in order to avoid reinventing bootstrapping
> fixes.


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

Re: PATH and security

[Jim Meyering]

Eric Blake <[EMAIL PROTECTED]> wrote:
> According to Jim Meyering on 4/22/2008 5:13 PM:
> |>> If security isn't enough of an argument, you can consider this yet another
> |>> reason not to put "." early in your PATH.  Please consider removing
> |>> "." from your PATH altogether.
>
> | Besides, I recognize that no system is immune from risk.
> | I.e., a bug in my browser may allow malicious code to create
> | that /tmp/ls file you mentioned.
>
> I personally like having . in my PATH on systems I manage, but only at the
> end and never first, so I can guarantee that any important program (like
> /bin/ls) cannot be inadvertently replaced by a malicious /tmp/ls.

With "." anywhere in your PATH, you're still subject to the risk of the
classic typo-trojan.  I.e., if someone/something creates /tmp/sl and
you type e.g., "sl" instead of "ls" while in /tmp.


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