Re: sort of new branch: next

Jim Meyering wrote: > I've pushed a few changes to a new "next" branch. > I expect to rebase it against master. Would you like others to push desired changes there for review? > > $ g shortlog HEAD ^master It would be nice to have the web interface highlight these changesets in some way. che

Re: sort of new branch: next

Pádraig Brady wrote: > Jim Meyering wrote: >> I've pushed a few changes to a new "next" branch. >> I expect to rebase it against master. > > Would you like others to push desired changes there > for review? Sure, if you or Eric are interested, but first I'll have to adjust the server-side update

Re: option abbreviation exceptions

Eric Blake wrote: > src/truncate.c: printf (_("Usage: %s OPTION... FILE...\n"), > program_name); > > Inconsistent formatting. Do we really want to require either -r or -s, or > would it make sense to make OPTION optional, in which case the default is > -s0? I'm not sure that's a desira

[bug #1212] wishlist: ls sort case insensitive option

Follow-up Comment #10, bug #1212 (project coreutils): link - http://pretty-lemon.com ___ Reply to this item at: ___ Message sent via/by Savannah http

Re: sort of new branch: next

Pádraig Brady wrote: >> Or just run "gitk next ^master" from a cloned directory. > > Ah ok, that's probably fine. > I assumed the commits where inconspicuous among the > other commits and ordered on their original commit dates. > But I think they will be tagged as "next", and that > you've only ac

Re: sort of new branch: next

Jim Meyering wrote: > Pádraig Brady wrote: > >> Jim Meyering wrote: >>> I've pushed a few changes to a new "next" branch. >>> I expect to rebase it against master. >> Would you like others to push desired changes there >> for review? > > Sure, if you or Eric are interested, but first I'll have t

Re: option abbreviation exceptions

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Pádraig Brady on 12/30/2008 2:46 AM: >> Usage: truncate [OPTION]... [FILE]... > > Is supporting stdin a useful enhancement? > Maybe if you can get the shell to open > different files based on some condition, > though again that seems a li

[bug #1212] wishlist: ls sort case insensitive option

Follow-up Comment #11, bug #1212 (project coreutils): http://asian-sex-videos.pornlivenews.com/ asian sex videos http://hotblondesex.pornlivenews.com/ hot blonde sex http://swingersexvideos.pornlivenews.com/ swinger sex videos http://freelatinaspornvids.pornlivenews.com/free lat

[PATCH] improve M4 quoting

* configure.ac: Add quotes. * gl/m4/mgetgroups.m4 (gl_MGETGROUPS): Likewise. * m4/boottime.m4 (GNULIB_BOOT_TIME): Likewise. * m4/check-decl.m4 (gl_CHECK_DECLS): Likewise. * m4/gmp.m4 (cu_GMP): Likewise. * m4/jm-macros.m4 (coreutils_MACROS, gl_CHECK_ALL_HEADERS): Likewise. (gl_CHECK_ALL_TYPES): Lik

Re: a fix for color ls with wrapped lines.

Jan Engelhardt wrote: >>>Thanks for the report. >>>Can you list a few terminal emulators that are affected? >>>The more the better. >> >>This affects at least linux vt, xterm and urxvt, possibly much more. >> >>>Also, please tell precisely how to demonstrate the problem. >> >>touch .foo >>(mus

Re: a fix for color ls with wrapped lines.

On Tuesday 2008-12-30 21:47, Jim Meyering wrote: > >Thanks for the follow-up. >I've just tried to reproduce the problem using the latest >version of ls, invoked from a linux vt, then xterm, aterm and rxvt >windows. Each time, I did this in an empty directory: > > seq 100|xargs touch; touch z.foo

Re: sort of new branch: next

Jim Meyering wrote: > I've pushed a few changes to a new "next" branch. > I expect to rebase it against master. > > $ g shortlog HEAD ^master > build: use dist-xz, not dist-lzma > cleanup/modernize: don't test HAVE_MBRTOWC; now gnulib provides it > portability: accommodat

chown and bash trashed part of system

bash version 3.2.29 and chown version 6.10 Permisions in home folder on hidden directories with root and not vincent. $ sudo chown -R vincent:vincent * changed all but the hidden folders, so did not work for this situation $ sudo chown -R vincent:vincent .* Command very bad. .* wild ca

Re: chown and bash trashed part of system

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Vincent Chapman on 12/30/2008 8:09 PM: > $ sudo chown -R vincent:vincent .* > > Command very bad. > > .* wild card picked up directory entry '..' and like requested chown > descended into sub directories, BUT chown also ascended into

Re: chown and bash trashed part of system

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [please keep the list in the loop] According to Vincent Chapman on 12/30/2008 10:00 PM: > In /home I made a .temp folder > > Apparently not all shells in Unix handle globbing the same way. > > > In bash, sh, csh, and ksh: > > $ echo .* > . .. .tem

Re: chown and bash trashed part of system

Vincent Chapman wrote: > $ sudo chown -R vincent:vincent * When using -R and other commands in recursive mode you generally don't want to use '*'. Simply use '.' in that case. sudo chown -R vincent:vincent . The command will recurse down '.' directory and do what you wanted. That would have