Re: ls -v is still inconsistent

On Friday 20 of March 2009 22:25:30 Bob Proulx wrote: > Kamil Dudka wrote: > > On Friday 20 of March 2009 12:36:38 Bruno Haible wrote: > > > Jim Meyering wrote: > > > > Perhaps "~" isn't the only character we should treat that way. > > > > > > I'd say that '~' is pretty special here because it's us

[bug #25946] mv/cp/ls/cd cannot cope with leading dash (-) in directory names without path

Update of bug #25946 (project coreutils): Status:None => Invalid Open/Closed:Open => Closed ___ Follow-up Comment #2: And if you happe

[bug #25946] mv/cp/ls/cd cannot cope with leading dash (-) in directory names without path

Follow-up Comment #1, bug #25946 (project coreutils): cd -- "- test -" should also work fine. This is not only expected behavior for cd and ls, but for virtually any command on a Unix-style system. Arguments that begin with a "-" are interpreted as strings of options (think of "ls -ltc"), so cd

[bug #25946] mv/cp/ls/cd cannot cope with leading dash (-) in directory names without path

URL: Summary: mv/cp/ls/cd cannot cope with leading dash (-) in directory names without path Project: GNU Core Utilities Submitted by: hmu Submitted on: Fr 20 Mär 2009 22:43:15 GMT Cat

Re: ls -v is still inconsistent

Kamil Dudka wrote: > On Friday 20 of March 2009 12:36:38 Bruno Haible wrote: > > Jim Meyering wrote: > > > Perhaps "~" isn't the only character we should treat that way. > > > > I'd say that '~' is pretty special here because it's used as backup file > > suffix by many text editors. Which is not th

Re: misalignment in ls -l in fr_FR locale

Samuel Thibault wrote: > Pádraig Brady, le Fri 20 Mar 2009 12:23:29 +, a écrit : >> >> Note that I get shorter abmon values, and also the alignment is fine? > > That's because it's an old glibc. You can try using some other locale > that has variable sized-abmon, like possibly ar_JO, ar_LB, ar

Re: coreutils 7.1.49-ebb9 FTB risc/HP-UX

Eric Blake wrote: > According to Jim Meyering on 3/20/2009 12:34 AM: >> I like it. Thanks. >> However, I'd like to keep O_FULLBLOCK as a single-bit value. >> That's slightly less surprising, and makes the change a tad >> smaller. How about this? > > Fair enough; I debated about doing it myself.

Re: Way to bypass or disable for ls hard link highlighting

Kamil Dudka wrote: > other cases the behavior is equivalent to symbolic link. I propose a one-line > patch like this: > http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=f3f1ccfd871ee395e7fafc051c1b7dedb39fdfc9 > > With the patch user can choose to not highlight hardlinks in his

Re: coreutils 7.1.49-ebb9 FTB sparc/Solaris, AIX

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Andreas Schwab on 3/20/2009 7:20 AM: > Eric Blake writes: > >> But C99 also states: >> >> If the same qualifier appears more than once in the same >> specifier-qualifier-list, either directly or via one or more typedefs, the >> behavior

Re: coreutils 7.1.49-ebb9 FTB sparc/Solaris, AIX

Eric Blake writes: > But C99 also states: > > If the same qualifier appears more than once in the same > specifier-qualifier-list, either directly or via one or more typedefs, the > behavior is the same as if it appeared only once. This paragraph is new in C99. Thus it is not a bug if a C89 com

Re: Way to bypass or disable for ls hard link highlighting

On Friday 20 of March 2009 12:15:34 Pádraig Brady wrote: > Wes Morgan wrote: > > The new "hard link" highlighting would be nicer if it was optional. I > > have lots of files with an "original" name that are also hard links to a > > canonicalized version in another directory hierarchy. Instead of sh

Re: misalignment in ls -l in fr_FR locale

Pádraig Brady, le Fri 20 Mar 2009 12:23:29 +, a écrit : > Samuel Thibault wrote: > > $ ls -l > > drwxr-xr-x 5 samy samy 4,0K mars 17 22:33 tmp/ > > drwx-- 5 samy samy 4,0K févr. 12 18:20 u/ > > > > Because in the fr_FR locale abmon does not have a constant width, the > > content of ls -l

Re: 7.1.xx test results

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Matthew Woehlke on 3/19/2009 12:41 PM: >> -# Copyright (C) 2008 Free Software Foundation, Inc. >> +# Copyright (C) 2008-2009 Free Software Foundation, Inc. > > Nit: I thought GNU standard was "2008, 2009"? (But I could be getting > mixed

Re: coreutils 7.1.49-ebb9 FTB sparc/Solaris, AIX

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [adding bug-gnulib] According to Matthew Woehlke on 3/19/2009 3:07 PM: > Jim Meyering wrote: >> Matthew Woehlke wrote: >>> Also, here is a different (AIX-only) error: >>> >>> cc -qlanglvl=ansi -qlanglvl=ansi -g -o ln ln.o libver.a >>> ../lib/libco

Re: ls -v is still inconsistent

On Friday 20 of March 2009 12:36:38 Bruno Haible wrote: > Jim Meyering wrote: > > Perhaps "~" isn't the only character we should treat that way. > > I'd say that '~' is pretty special here because it's used as backup file > suffix by many text editors. Which is not the case for '_', '-', and > othe

Re: coreutils 7.1.49-ebb9 FTB risc/HP-UX

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Jim Meyering on 3/20/2009 12:34 AM: > I like it. Thanks. > However, I'd like to keep O_FULLBLOCK as a single-bit value. > That's slightly less surprising, and makes the change a tad > smaller. How about this? Fair enough; I debated abou

Re: misalignment in ls -l in fr_FR locale

Samuel Thibault wrote: > Hello, > > $ ls -l > drwxr-xr-x 5 samy samy 4,0K mars 17 22:33 tmp/ > drwx-- 5 samy samy 4,0K févr. 12 18:20 u/ > > Because in the fr_FR locale abmon does not have a constant width, the > content of ls -l is misaligned. Locale standards require abday to have > a co

Re: ls -v is still inconsistent

Jim Meyering wrote: > Perhaps "~" isn't the only character we should treat that way. I'd say that '~' is pretty special here because it's used as backup file suffix by many text editors. Which is not the case for '_', '-', and others. Bruno ___ Bug-co

Re: Way to bypass or disable for ls hard link highlighting

Pádraig Brady wrote: > Wes Morgan wrote: >> The new "hard link" highlighting would be nicer if it was optional. I >> have lots of files with an "original" name that are also hard links to a >> canonicalized version in another directory hierarchy. Instead of showing >> the original coloring based on

Re: ls -v is still inconsistent

Kamil Dudka wrote: > On Thursday 19 March 2009 11:27:11 Sven Joachim wrote: >> While the ordering of hidden files in "ls -v" seems to be fixed >> now, there are still inconsistencies. Here's what I get in the latest >> snapshot: >> >> , >> >> | LANG=C /usr/local/src/coreutils-7.1.63-8e6a6/src

Re: Way to bypass or disable for ls hard link highlighting

Wes Morgan wrote: > The new "hard link" highlighting would be nicer if it was optional. I > have lots of files with an "original" name that are also hard links to a > canonicalized version in another directory hierarchy. Instead of showing > the original coloring based on the extension, they show t

Re: ls -v is still inconsistent

On Thursday 19 March 2009 11:27:11 Sven Joachim wrote: > While the ordering of hidden files in "ls -v" seems to be fixed > now, there are still inconsistencies. Here's what I get in the latest > snapshot: > > , > > | LANG=C /usr/local/src/coreutils-7.1.63-8e6a6/src/ls -alv > | total 0 > | drwx

Re: root check failed for install-C-root

On Wednesday 18 March 2009 18:31:29 Kamil Dudka wrote: > Any idea how to reproduce the test failure? Note I've tested it with the fresh Ubuntu installation and the updated one. Kamil ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gn

Re: ls - French translation of N_("%b %e %Y")

2009/3/20 Bruno Haible : > Eric Blake wrote: >> It specifically states that results are unspecified for >> other things, like %b, where there could be more bytes than screen >> columns.  Which means we should be free to interpret things in the way >> that makes the most sense, by interpreting %5b a