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
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:
>
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.
>
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
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
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
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:
>
>
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
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
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
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
-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
-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
[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
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
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
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
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
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.
__
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
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/
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
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
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
"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
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
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
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.
-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
29 matches
Mail list logo
