Re: [PATCH] Add svg to the dircolors list
Jim Meyering wrote: Matthew Woehlke [EMAIL PROTECTED] wrote: Mike Frysinger wrote: diff --git a/src/dircolors.hin b/src/dircolors.hin +.svg 01;35 How about .svgz? It's already there. Ok, must've snuck in when I wasn't looking. Thanks. -- Matthew ENLS: translation failed (Google was not your friend this time) ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: sort --compare-version
Bob Proulx wrote:
@@ -353,6 +354,7 @@ Other options:\n\
+ -V, --compare-version compare embedded numbers as version numbers\n\
Looking at the existing options I see these:
Ordering options:
-g, --general-numeric-sort compare according to general numerical value
-M, --month-sortcompare (unknown) `JAN' ... `DEC'
-n, --numeric-sort compare according to string numerical value
That would mean to me that version comparison would need to be of the
form --something-sort and would need to be in the Ordering
options: section and not the Other options: section. I suppose
that this option should be called --version-sort instead in order to
be consistent with the already existing options.
But! Using --version-sort conflicts with --version.
Yep. That's the reason for the compare- prefix. I didn't like
``--compare-version-sort'' for some sort of reason, too. Ultimately,
someone pick another name if compare-version is aesthetically bad.
I do think it needs to be moved into the Ordering options: section
through regardless.
Yes.
+compare_version (char *restrict texta, size_t lena,
+ char *restrict textb, size_t lenb)
+{
+ int diff;
+ char sv_a = texta[lena];
+ char sv_b = textb[lenb];
+ texta[lena] = sv_a;
+ textb[lenb] = sv_b;
Pardon me for not looking but why is texta[lena] saved, zeroed, and
then restored? A clue left behind there would be nice.
OK. The reason is that strverscmp works on NUL terminated strings.
The specified fields are not guaranteed to be NUL terminated, but
are guaranteed to be writable.
{
-char opts[7];
+char opts[sizeof short_options];
char *p = opts;
if (key-ignore == nondictionary)
*p++ = 'd';
I don't like the magic number 7 there (and I think it should have been
8 anyway meaning that you have also fixed a bug to be noted in the log
entry) but using sizeof short_options I think is not correct either.
It is guaranteed to be sufficient and certain to be inconsequential.
Yes, it uses a half dozen extra bytes of memory. That can't be
a problem.
I think I like this following technique better. In my mind it makes
it much more self-documenting without using extra space.
{
char opts[sizeof dfgiMnVR];
char *p = opts;
if (key-ignore == nondictionary)
*p++ = 'd';
I think this is an improvement that requires more maintenance than
simply making the buffer big enough for any conceivable list of
options. So, marginally more intelligible and marginally more
maintenance. Looks good to me. :)
In general I like the feature very much. Thank you for working on
this. Have you submitted the necessary copyright paperwork to the FSF
for contribution to coreutils?
All the paperwork is in place.
Would you also be able to work on
other things needed to get this into coreutils such as ChangeLog
entry, test cases, info documentation, and NEWS entry? I would be
willing to help with these tasks.
I'm glad you're willing to help 'cuz this isn't my day job. :)
Cheers - Bruce
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: sort --compare-version
Bruce Korb [EMAIL PROTECTED] writes:
Yep. That's the reason for the compare- prefix. I didn't like
``--compare-version-sort'' for some sort of reason, too. Ultimately,
someone pick another name if compare-version is aesthetically bad.
How about making it --sort=KEYWORD, with KEYWORD in
{general-numeric,month,numeric,random,version}?
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
And now for something completely different.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: sort --compare-version
On Feb 6, 2008 10:59 AM, Andreas Schwab [EMAIL PROTECTED] wrote:
Bruce Korb [EMAIL PROTECTED] writes:
Yep. That's the reason for the compare- prefix. I didn't like
``--compare-version-sort'' for some sort of reason, too. Ultimately,
someone pick another name if compare-version is aesthetically bad.
How about making it --sort=KEYWORD, with KEYWORD in
{general-numeric,month,numeric,random,version}?
Yep. That's _very_ nice. Just a little beyond the energy level I had at
the time. :) Thanks.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: sort --compare-version
Andreas Schwab [EMAIL PROTECTED] wrote:
Bruce Korb [EMAIL PROTECTED] writes:
Yep. That's the reason for the compare- prefix. I didn't like
``--compare-version-sort'' for some sort of reason, too. Ultimately,
someone pick another name if compare-version is aesthetically bad.
How about making it --sort=KEYWORD, with KEYWORD in
{general-numeric,month,numeric,random,version}?
I like it.
Then it's easy to skip the short-named command-line option.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: sort --compare-version
Andreas Schwab wrote on 06-02-08 19:59:
Bruce Korb [EMAIL PROTECTED] writes:
Yep. That's the reason for the compare- prefix. I didn't like
``--compare-version-sort'' for some sort of reason, too. Ultimately,
someone pick another name if compare-version is aesthetically bad.
How about making it --sort=KEYWORD, with KEYWORD in
{general-numeric,month,numeric,random,version}?
Andreas.
That's what I thought. But I suppose the single-letter
options that are valid now will have to be kept also?
bjd
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: sort --compare-version
Jim Meyering wrote:
Andreas Schwab wrote:
How about making it --sort=KEYWORD, with KEYWORD in
{general-numeric,month,numeric,random,version}?
I like it.
Then it's easy to skip the short-named command-line option.
+1
I very much like that idea too.
Bob
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: sort --compare-version
Bruce Korb wrote:
Bob Proulx wrote:
I don't like the magic number 7 there (and I think it should have been
8 anyway meaning that you have also fixed a bug to be noted in the log
entry) but using sizeof short_options I think is not correct either.
It is guaranteed to be sufficient and certain to be inconsequential.
Yes, it uses a half dozen extra bytes of memory. That can't be
a problem.
In my mind it wasn't about the extra memory. As you noted it was an
insignificant amount. My concern was that it tied the size of that
string to something that strictly speaking was something different.
It would always have been larger and would have been functional. But
it isn't really the size of the thing that we needed. Reading the
code later there wasn't the mental tie between the two things that I
felt needed to be tied together.
I think I like this following technique better. In my mind it makes
it much more self-documenting without using extra space.
{
char opts[sizeof dfgiMnVR];
char *p = opts;
if (key-ignore == nondictionary)
*p++ = 'd';
I think this is an improvement that requires more maintenance than
simply making the buffer big enough for any conceivable list of
options. So, marginally more intelligible and marginally more
maintenance. Looks good to me. :)
Anyone looking to add option letters would definitely be drawn to that
spot because it looks very similar to the getopts string of options
and would naturally keep it up to date. I like it better than the
bare number approach but even that wasn't bad, just something that
could be slightly better. Obviously I like it better than using a
bounded sizeof something else that's bigger. So I will simply
disagree that it is more maintenance because I think it would be less
maintenance. But either way if we are agreed that it may appear more
intelligible then it is a win.
I'm glad you're willing to help 'cuz this isn't my day job. :)
Do you work the midnight shift? ;-)
Bob
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Feature request: rm option that supports trash (plain text)
On Feb 5, 2008 12:59 PM, Bob Proulx [EMAIL PROTECTED] wrote: Wilfred wrote: It would be great if rm supported moving a file to a freedesktop.org compliant trash folder. This woud save much heartache by giving a 'safer' option for newbies. This is easily done. Simply create an alias that moves the file instead of removing it. alias rm=mv --target-directory=$HOME/.Trash/ But please don't make this a system default since this behavior is not appreciated by many. Bob ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils Additionally, I use the --backup option to prevent overwriting existing files folders in the trash (in order to be similar to the Recycle Bin behavior). # my del alias del='mv --verbose --backup=simple --suffix=$(date +.(%F_%T)) --target-directory=$HOME/.Trash/' Steve ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Feature request: rm option that supports trash (plain text)
Steve Ward wrote: Additionally, I use the --backup option to prevent overwriting existing files folders in the trash (in order to be similar to the Recycle Bin behavior). # my del alias del='mv --verbose --backup=simple --suffix=$(date +.(%F_%T)) --target-directory=$HOME/.Trash/' I updated the FAQ entry and added this example. Bob ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] mkdir/split: send --verbose output to stdout
Steven Schubiger [EMAIL PROTECTED] wrote:
+2008-02-01 Steven Schubiger [EMAIL PROTECTED]
+
+ * src/mkdir.c: Send --verbose output to stdout.
+ * src/split.c: Likewise.
+ Update texinfo documentation for split.
+ Adjust tests for mkdir/split.
+ * tests/mkdir/p-v: Capture verbose output which previously was
+ being emitted to stderr from stdout.
+ * tests/misc/split-a: Likewise.
Thanks for the patch.
I've made some minor changes and handled the usual administrivia.
mkdir, split: write --verbose output to stdout, not stderr.
* src/mkdir.c (verbose_output): New function.
(announce_mkdir): Use it.
* src/split.c (usage): Update.
* src/split.c (cwrite): Write to stdout, not stderr.
* doc/coreutils.texi (split invocation): Remove the mention
of --verbose output being printed to stderr.
* tests/mkdir/p-v: Redirect stdout, not stderr.
* tests/misc/split-a: Likewise.
* NEWS: Mention this change.
* TODO: Remove this item.
Signed-off-by: Jim Meyering [EMAIL PROTECTED]
---
ChangeLog | 14 ++
NEWS |4
TODO |8
doc/coreutils.texi |2 +-
src/mkdir.c| 17 +++--
src/split.c|8
tests/misc/split-a |4 ++--
tests/mkdir/p-v|4 ++--
8 files changed, 42 insertions(+), 19 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index c6c44c2..597db63 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,17 @@
+2008-02-06 Steven Schubiger [EMAIL PROTECTED]
+
+ mkdir, split: write --verbose output to stdout, not stderr.
+ * src/mkdir.c (verbose_output): New function.
+ (announce_mkdir): Use it.
+ * src/split.c (usage): Update.
+ * src/split.c (cwrite): Write to stdout, not stderr.
+ * doc/coreutils.texi (split invocation): Remove the mention
+ of --verbose output being printed to stderr.
+ * tests/mkdir/p-v: Redirect stdout, not stderr.
+ * tests/misc/split-a: Likewise.
+ * NEWS: Mention this change.
+ * TODO: Remove this item.
+
2008-02-04 Jim Meyering [EMAIL PROTECTED]
* Makefile.maint (announcement): Remove stale comment.
diff --git a/NEWS b/NEWS
index 0d2d97d..3d714fc 100644
--- a/NEWS
+++ b/NEWS
@@ -10,6 +10,10 @@ GNU coreutils NEWS-*-
outline -*-
rmdir --ignore-fail-on-non-empty detects and ignores the failure
in more cases when a directory is empty.
+** Consistency
+
+ mkdir and split now write --verbose output to stdout, not stderr.
+
* Noteworthy changes in release 6.10 (2008-01-22) [stable]
diff --git a/TODO b/TODO
index a442620..3cec054 100644
--- a/TODO
+++ b/TODO
@@ -46,14 +46,6 @@ And once that's done, add an exclusion so that `cp --link'
no longer incurs the overhead of saving src. dev/ino and dest. filename
in the hash table.
-See if we can be consistent about where --verbose sends its output:
- These all send --verbose output to stdout:
-head, tail, rm, cp, mv, ln, chmod, chown, chgrp, install, ln
- These send it to stderr:
-shred mkdir split
- shred must write --verbose output to stderr
- readlink is different
-
Write an autoconf test to work around build failure in HPUX's 64-bit mode.
See notes in README -- and remove them once there's a work-around.
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index 40aee6f..aca5fbd 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -2838,7 +2838,7 @@ Use digits in suffixes rather than lower-case letters.
@itemx --verbose
@opindex --verbose
-Write a diagnostic to standard error just before each output file is opened.
+Write a diagnostic just before each output file is opened.
@end table
diff --git a/src/mkdir.c b/src/mkdir.c
index 0704077..3781065 100644
--- a/src/mkdir.c
+++ b/src/mkdir.c
@@ -1,5 +1,5 @@
/* mkdir -- make directories
- Copyright (C) 90, 1995-2002, 2004-2007 Free Software Foundation, Inc.
+ Copyright (C) 90, 1995-2002, 2004-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
@@ -79,6 +79,19 @@ Mandatory arguments to long options are mandatory for short
options too.\n\
exit (status);
}
+/* Verbose formatted output of variable count of arguments. */
+static void
+verbose_output (FILE *fp, char const *fmt, ...)
+{
+ va_list ap;
+ fputs (program_name, fp);
+ fputs (: , fp);
+ va_start (ap, fmt);
+ vfprintf (fp, fmt, ap);
+ va_end (ap);
+ fputc ('\n', fp);
+}
+
/* Options passed to subsidiary functions. */
struct mkdir_options
{
@@ -105,7 +118,7 @@ announce_mkdir (char const *dir, void *options)
{
struct mkdir_options const *o = options;
if (o-created_directory_format)
-error (0, 0, o-created_directory_format, quote (dir));
+verbose_output (stdout, o-created_directory_format, quote (dir));
