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_directo
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: 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: 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: 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
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
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
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
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
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 ---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: [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