Re: Support in sort for human-readable numbers

"Vitali Lovich" wrote: ... >> because I think it's a common enough format and getting >> more common since it's an IEC defined standard. >> >>> and wouldn't be better served by >>> pre-processing the text before sort & post-processing it after as >>> necessary? >> >> that's a little awkward and in

Re: Support in sort for human-readable numbers

On Wed, Jan 7, 2009 at 3:17 AM, Jim Meyering wrote: > "Vitali Lovich" wrote: > ... >>> because I think it's a common enough format and getting >>> more common since it's an IEC defined standard. >>> and wouldn't be better served by pre-processing the text before sort & post-processing i

Re: Support in sort for human-readable numbers

On Wed, Jan 7, 2009 at 2:52 AM, Paul Eggert wrote: > I looked at the patch > and have a > few comments: > > * There's no documentation, either in the .texi file or in the --help > string. That's often the hardest part to get right. I ag

Re: Support in sort for human-readable numbers

Oh, and if my prior e-mail seems a bit abrupt, I apologize. I don't mean to be rude. It is getting late, and I probably should've waited until morning to compose my reply. On Wed, Jan 7, 2009 at 4:21 AM, Vitali Lovich wrote: > On Wed, Jan 7, 2009 at 2:52 AM, Paul Eggert wrote: >> I looked at t

Re: stat signed/unsigned

Jim Meyering wrote: > Pádraig Brady wrote: > ... >>> That sounds like it could be rather invasive... >>> >From an aesthetics/readability point of view, I'm not sure >>> I like the idea of using ST_SIZE (st) in place of "st.st_size". >> Well it would be more consistent as we already use ST_BLKSIZE

No more "Your first commit: the quick and dirty way"

In the file HACKING, please remove the "Your first commit: the quick and dirty way". Just directly mention the right way, "Make your changes on a private "topic" branch" It only costs the user a couple more commands. Else you are starting many first time git users on the wrong foot; days of miser

Re: cp/mv: add -n option to not overwrite target (Ubuntu bug #229182)

On Wednesday 07 January 2009 08:35:24 Jim Meyering wrote: > Have you considered other long-option names? > I prefer --no-clobber. or maybe --no-overwrite In this case I prefer --no-overwrite, but feel free to change it. > --- > Please adjust the NEWS entry: > > - cp/mv new op

Re: cp/mv: add -n option to not overwrite target (Ubuntu bug #229182)

Kamil Dudka wrote: > On Wednesday 07 January 2009 08:35:24 Jim Meyering wrote: >> Have you considered other long-option names? >> I prefer --no-clobber. or maybe --no-overwrite > In this case I prefer --no-overwrite, but feel free to change it. Hi Kamil, --no-clobber gets a few more matches in

Re: cp/mv: add -n option to not overwrite target (Ubuntu bug #229182)

On Wednesday 07 January 2009 17:08:04 Jim Meyering wrote: > --no-clobber gets a few more matches in C sources than --no-overwrite, > > 57 http://www.google.com/codesearch?q=\-\-no\-clobber+lang:c > 40 http://www.google.com/codesearch?q=\-\-no\-overwrite+lang:c > > Regarding uses, it appears t

Re: cp/mv: add -n option to not overwrite target (Ubuntu bug #229182)

Kamil Dudka wrote: > On Wednesday 07 January 2009 17:08:04 Jim Meyering wrote: >> --no-clobber gets a few more matches in C sources than --no-overwrite, >> >> 57 http://www.google.com/codesearch?q=\-\-no\-clobber+lang:c >> 40 http://www.google.com/codesearch?q=\-\-no\-overwrite+lang:c >> >>

Bug in date command

The date command reports the wrong ISO week number in some cases. For example: $ date -d 2008-12-31 +%Y%V 200801 Clearly the last day of the year can't be in the first week of that year. -- Bob Kline http://www.rksystems.com mailto:bkl...@rksystems.com __

Re: Bug in date command

Bob Kline rksystems.com> writes: > > The date command reports the wrong ISO week number in some cases. For > example: > > $ date -d 2008-12-31 +%Y%V > 200801 Not a bug in date, but in your misuse of incompatible formats. 2008-12-31 is in the first ISO week of 2009, as evidenced by: $ date

Re: Bug in date command

Bob Kline wrote: > The date command reports the wrong ISO week number in some cases. For > example: > > $ date -d 2008-12-31 +%Y%V > 200801 > > Clearly the last day of the year can't be in the first week of that > year. According to ISO 8601 it can. See the official standard for the authoritat

Re: Bug in date command

Eric Blake wrote: > There seems to always be a rash of "bug" reports about date at the > turn of the year (and also around daylight savings changes), due to > the large number of people who don't realize the subtleties > involved. Perhaps we should create a FAQ entry with the most common > of thes

can't find out cumin-admin command

hi, sir i have met a problem , i have install cumin and mrg management . now i install cumin -0.1-3.el5, mrgmanagement -1.0-2.noarch it setup succeed for it . and database have create running cumin-database-init it's ok su cuminit's ok cumin-admin adduser testuserdoens't work show me

Re: can't find out cumin-admin command

yuan xinfang wrote: > i have met a problem , i have install cumin and mrg management . > > now i install cumin -0.1-3.el5, mrgmanagement -1.0-2.noarch You have reached the GNU Coreutils mailing list. The GNU Coreutils are the basic file, shell and text manipulation utilities of the GNU Operating

Re: Bug in date command

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bob Proulx on 1/7/2009 3:12 PM: > > http://www.gnu.org/software/coreutils/faq/coreutils-faq.html#The-date-command-is-not-working-right_002e > > How does that look? A couple of nits: "The parsing of dates with date --date=STRING is a

Re: cp/mv: add -n option to not overwrite target (Ubuntu bug #229182)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Jim Meyering on 1/7/2009 12:27 PM: >>> Anyone else have a preference? >> Now the option is --no-clobber in attached patch. Anyway the change is >> trivial. No problem to change it if there will be a consensus >> for --no-overwrite or somet

Re: Bug in date command

Eric Blake wrote: > A couple of nits: > > "The parsing of dates with date --date=STRING is a GNU extension and not > covered by any standards beyond those to which GNU holds itself." Not > entirely true any longer, now that POSIX 2008 requires that 'touch -d > STRING' parse a limited format of IS

Re: cp/mv: add -n option to not overwrite target (Ubuntu bug #229182)

Eric Blake wrote: > According to Jim Meyering on 1/7/2009 12:27 PM: Anyone else have a preference? >>> Now the option is --no-clobber in attached patch. Anyway the change is >>> trivial. No problem to change it if there will be a consensus >>> for --no-overwrite or something else. >>> >> >> T