Re: Problems building coreutils HEAD against gnulib HEAD

2008-02-18 Thread Eric Blake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bob Proulx on 2/18/2008 6:56 PM: |> ./bootstrap: aclocal --force -I m4 ... |> aclocal: aclocal: file `m4/isnan.m4' does not exist |> 1 | | Not sure about that. But I am, having seen it myself. It happens when you have a stale symlink fr

Re: Problems building coreutils HEAD against gnulib HEAD

2008-02-18 Thread Bob Proulx
James Youngman wrote: > I found I had been testing with a sufficiently out-of-date gnulib to > prevent coreutils' "make dist" from working. I updated it and now > "bootstrap" doesn't work :) Building coreutils is somewhat involved because it needs quite new versions of a number of dependencies.

Problems building coreutils HEAD against gnulib HEAD

2008-02-18 Thread James Youngman
I found I had been testing with a sufficiently out-of-date gnulib to prevent coreutils' "make dist" from working. I updated it and now "bootstrap" doesn't work :) Should I be using a slightly older version of gnulb to build git coreutils? Is there any mapping between compatible revisions? $ fo

bug in the command "du"

2008-02-18 Thread Jochen Röder
Hallo, i've found a bug in the command "du" When i list recursivly directories and i only want to see the binary count of all files. I become a wrong result. The command e.g. "du -ab" add the bytes from "." in every directory to the result. Or did you have a parameterset to list the bytes onl

Re: [PATCH] Check the order of the input by default, if there are unpairable input lines.

2008-02-18 Thread Jim Meyering
"James Youngman" <[EMAIL PROTECTED]> wrote: > On Feb 18, 2008 11:12 PM, Jim Meyering <[EMAIL PROTECTED]> wrote: >> Thanks for pursuing this. >> Same tests as before? > > Yes, one had to be removed (it verified that no oder checking was done > by default). > >> IMHO, it's good to keep them in the sa

Re: [PATCH] Check the order of the input by default, if there are unpairable input lines.

2008-02-18 Thread James Youngman
On Feb 18, 2008 11:12 PM, Jim Meyering <[EMAIL PROTECTED]> wrote: > Thanks for pursuing this. > Same tests as before? Yes, one had to be removed (it verified that no oder checking was done by default). > IMHO, it's good to keep them in the same change set. > > There are a few trailing blanks, too

Re: [PATCH] Check the order of the input by default, if there are unpairable input lines.

2008-02-18 Thread Jim Meyering
James Youngman <[EMAIL PROTECTED]> wrote: > This patch amends my previous changes to join.c to enable > order-checking by default for the case where the user is not making > use of the extension of processing unsorted inputs containing only > pairable lines. This idea was suggestied by Pádraig Bra

Re: [PATCH] better diagnostics for seq

2008-02-18 Thread Jim Meyering
Steven Schubiger <[EMAIL PROTECTED]> wrote: > Attached is a revised patch that should take "appropriately" care of > your suggestions. I ran make check and all tests passed. Furthermore, > I checked coreutils.texi, but there seems to be no relevant documentation > for seq with regard to diagnostics

[PATCH] Check the order of the input by default, if there are unpairable input lines.

2008-02-18 Thread James Youngman
This patch amends my previous changes to join.c to enable order-checking by default for the case where the user is not making use of the extension of processing unsorted inputs containing only pairable lines. This idea was suggestied by Pádraig Brady. 2008-02-18 James Youngman <[EMAIL PROTEC

Re: sort --compare-version

2008-02-18 Thread Andreas Schwab
Jim Meyering <[EMAIL PROTECTED]> writes: > Do you feel like adding a few tests (tests/sort/Test.pm) to exercise > the new feature, and adding to coreutils.texi and NEWS? Here is an updated patch. Andreas. 2008-02-18 Andreas Schwab <[EMAIL PROTECTED]> Add --sort option. * src/

Re: new sort option (or one I don't know about that already exists...:-) )

2008-02-18 Thread James Youngman
On Feb 18, 2008 6:41 PM, Linda Walsh <[EMAIL PROTECTED]> wrote: > Am I the only one who likes to do things like [...] > du -sh * I hope so; in the general case (i.e. with other tools) it can have unpredictable effects. Using ./* instead of * is safer. James. __

Re: [PATCH] better diagnostics for seq

2008-02-18 Thread Steven Schubiger
Jim Meyering <[EMAIL PROTECTED]> wrote: > Thanks for working on that. Attached is a revised patch that should take "appropriately" care of your suggestions. I ran make check and all tests passed. Furthermore, I checked coreutils.texi, but there seems to be no relevant documentation for seq with re

Re: chown should catch null owner:group

2008-02-18 Thread Linda Walsh
Eric Blake wrote: But why should it be an absolute error? We have already pointed out to you that resetting to defaults is not necessarily a no-op, I haven't tested every case, but this isn't what it did on my machine. It didn't reset the g+s bit on a dir, and the only time it ch

Re: new sort option (or one I don't know about that already exists...:-) )

2008-02-18 Thread Linda Walsh
Jim Meyering wrote: This has been proposed before, and would be a welcome addition. We're just waiting for someone to prepare a proper patch, (documentation, NEWS, tests, ChangeLog entries, copyright assignment) Oh the benefits of Open Source! *forced-grin*... Hey, s

Re: chown should catch null owner:group

2008-02-18 Thread jidanni
EB> `:' EB> ~ If only a colon is given, or if NEW-OWNER is empty, neither the EB> ~ owner nor the group is changed. OK, I'll drop my case, but please add a comment to this documentation about "why" or "who knows why?" or the motivation behind or uses of, this case. Perhaps "just to be ort

Re: chown should catch null owner:group

2008-02-18 Thread Jim Meyering
[EMAIL PROTECTED] wrote: > LW> "chown -R ." gave an error > Try > DJ> chown -R . file > which should emit > "Holmes, you think you are changing the owner of FILE to be the same > as the owner of ".", but you have actually typed something else (-R > means recursive) which is an absolute error, about

Re: chown should catch null owner:group

2008-02-18 Thread Eric Blake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Linda Walsh on 2/18/2008 11:34 AM: Please don't top-post - on this list, we prefer to see replies in context. | What does it do? You said it reset somebody's boss's access so he could | not read some file. Was this hyperbole? When I

Re: chown should catch null owner:group

2008-02-18 Thread Eric Blake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to [EMAIL PROTECTED] on 2/18/2008 11:56 AM: | LW> "chown -R ." gave an error | Try | DJ> chown -R . file | which should emit | "Holmes, you think you are changing the owner of FILE to be the same | as the owner of ".", but you have actually

Re: chown should catch null owner:group

2008-02-18 Thread jidanni
LW> "chown -R ." gave an error Try DJ> chown -R . file which should emit "Holmes, you think you are changing the owner of FILE to be the same as the owner of ".", but you have actually typed something else (-R means recursive) which is an absolute error, about which the new improved chown command w

Re: new sort option (or one I don't know about that already exists...:-) )

2008-02-18 Thread Jim Meyering
Linda Walsh <[EMAIL PROTECTED]> wrote: > Am I the only one who likes to do things like > ls -lh1 >or > du -sh * > > and would like to be able to sort the output sizes "correctly"? > > I know I can du -s *|sort -n, but then it isn't "human readable". Right :-) This has been proposed before, an

new sort option (or one I don't know about that already exists...:-) )

2008-02-18 Thread Linda Walsh
Am I the only one who likes to do things like ls -lh1 or du -sh * and would like to be able to sort the output sizes "correctly"? I know I can du -s *|sort -n, but then it isn't "human readable". If I'm the only one...well...Foo!...:-) ___ Bug-c

Re: chown should catch null owner:group

2008-02-18 Thread Linda Walsh
What does it do? You said it reset somebody's boss's access so he could not read some file. Was this hyperbole? When I just tried it on a local directory, "chown -R ." gave an error, while "chown -R : ." appeared to do nothing on linux, under cygwin, it did reset 'group' id's from "null" (uid

Re: [PATCH] better diagnostics for seq

2008-02-18 Thread Jim Meyering
Pádraig Brady <[EMAIL PROTECTED]> wrote: > Steven Schubiger wrote: >> Attached is a patch that enhances seq's diagnostics. If you agree >> that this is the right way to go, I'll amend other files (ChangeLog, >> etc.) as needed. > > Seems sensible. This is what I get on a reasonably recent tree: > >

Re: [PATCH] better diagnostics for seq

2008-02-18 Thread Jim Meyering
Steven Schubiger <[EMAIL PROTECTED]> wrote: ... > Should we be additionally calling usage (EXIT_FAILURE); where now > error() with first argument as EXIT_FAILURE is being invoked? On one hand, I'm tempted to say if the user uses -f with a format string containing no % directive at all, then maybe

Re: [PATCH] better diagnostics for seq

2008-02-18 Thread Jim Meyering
Steven Schubiger <[EMAIL PROTECTED]> wrote: > Attached is a patch that enhances seq's diagnostics. If you agree > that this is the right way to go, I'll amend other files (ChangeLog, > etc.) as needed. Thanks for working on that. > diff --git a/src/seq.c b/src/seq.c > index 261a44b..4a6f96e 10064

Re: [PATCH] better diagnostics for seq

2008-02-18 Thread Jim Meyering
Pádraig Brady <[EMAIL PROTECTED]> wrote: > Steven Schubiger wrote: >> Attached is a patch that enhances seq's diagnostics. If you agree >> that this is the right way to go, I'll amend other files (ChangeLog, >> etc.) as needed. > > Seems sensible. This is what I get on a reasonably recent tree: >

Re: [PATCH] better diagnostics for seq

2008-02-18 Thread Steven Schubiger
Pádraig Brady <[EMAIL PROTECTED]> wrote: > Seems sensible. This is what I get on a reasonably recent tree: > > $ ./seq -f% 1 > ./seq: memory exhausted > > Note however that on gutsy I get the expected: > > $ seq -f% 1 > seq: invalid format string: `%' > Try `seq --help' for more information. >

Re: [PATCH] better diagnostics for seq

2008-02-18 Thread Pádraig Brady
Steven Schubiger wrote: > Attached is a patch that enhances seq's diagnostics. If you agree > that this is the right way to go, I'll amend other files (ChangeLog, > etc.) as needed. Seems sensible. This is what I get on a reasonably recent tree: $ ./seq -f% 1 ./seq: memory exhausted Note however

[PATCH] better diagnostics for seq

2008-02-18 Thread Steven Schubiger
Attached is a patch that enhances seq's diagnostics. If you agree that this is the right way to go, I'll amend other files (ChangeLog, etc.) as needed. Steven Schubiger diff --git a/src/seq.c b/src/seq.c index 261a44b..4a6f96e 100644 --- a/src/seq.c +++ b/src/seq.c @@ -185,12 +185,38 @@ scan_arg