[EMAIL PROTECTED] wrote:
J Would you *please* consider sending a precise suggestion
Sorry. OK, To both
man page:
--group-directories-first
group directories before files
And info page:
`--group-directories-first'
Group all the directories before the files and
Day wrote:
Yes, Bob. This problem came out because I set an alias for `ls' in
my .bashrc file
alias ls='ls -F --color'
So when I run the script what goes in to the [] test is `ls -F
--color -A ./dir' in fact. Thus issued the problem. Thanks for your
msg.
Hmm... But aliases are not used
Bob Proulx [EMAIL PROTECTED] wrote：
How did you happen to run into using 'ls --color' in a test such as
this? That seems an unfortunate option choice there. I recommend not
using --color there. But obviously you already thought of that and so
I have to ask what you were doing that caused
Hi Jim,
have you ever consider my follow-up patch to patch#3596 with the name:
ls_--group-directories-first_symlinks_to_dir_are_dirs_too.patch?
Thanks.
Bert
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
JM +(@option{-U}) disables this option altogether.
Looks good.
JM + disable with --sort=none (-U);\n\
Looks bad. One thinks disable by not using it in the first place.
Just word it like the first one above.
Yes the options are so complicated that one needs a n-to-the-nth-power
grid chart to sort
Eric Blake wrote:
It may be worth considering a patch to coreutils, such that plain --color
implies --color=auto rather than --color=always. For example, this would
match how 'git config' reacts when interpreting color options (where
'auto' and 'true' are synonyms, and 'always' must be
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Bert Wesarg on 2/12/2008 9:50 AM:
| Thanks for the patch, but a change in behavior like that
| requires some serious justification.
| I read the thread in the mail archive. Eric Blake questioned the symlink
| behavior in the first reply
Eric Blake wrote:
Additionally, IIRC, one of the reasons that --group-directories-first was
added was to mimic default behavior of a certain 'dir' program popular on
proprietary systems, but those systems did not have symlinks, so there
really is no prior art on how ls should behave on
Hello!
I'm a bit stumped with this behavior of ``readlink -f'', as it doesn't
match what I had expected.
#v+
[EMAIL PROTECTED]:~/tmp $ mkdir a-long
[EMAIL PROTECTED]:~/tmp $ touch a-long/f
[EMAIL PROTECTED]:~/tmp $ ln -s a-long a
[EMAIL PROTECTED]:~/tmp $ readlink -f a/f
$ cut -s' '
cut: invalid option --
Try `cut --help' for more information.
What do you mean, ?
I typed an -s. Give a proper error message.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Jim Meyering wrote on 12-02-08 15:50:
Pádraig Brady [EMAIL PROTECTED] wrote:
I can't think of any reason I would use `ls --format` over `find -printf`
Ha! Good point. Nor can I. I'll remove the TODO item.
Actually, from the perspective of modularity that is (justifiably)
hammered on so
Eric Blake [EMAIL PROTECTED] wrote:
According to Jim Meyering on 2/12/2008 11:30 AM:
|
| Here's the result I'll push in a day or two:
What about the corresponding patch to dircolors?
I haven't done that yet.
Would you like to do it?
FYI, this time, I'm adding a dist check to ensure the sets
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Jim Meyering on 2/12/2008 11:30 AM:
|
| Here's the result I'll push in a day or two:
|
| ls --color no longer outputs unnecessary escape sequences
| In --color mode, plain files do not get any color, not even white.
|
Jim Meyering [EMAIL PROTECTED] wrote:
Here's the result I'll push in a day or two:
ls --color no longer outputs unnecessary escape sequences
BTW, that patch reduces by up to about 60% the size of the output
of ls -C --color=always when there are many short-named files,
e.g., as you'd see
Jim Meyering wrote:
Bert Wesarg [EMAIL PROTECTED] wrote:
With the --group-directories-first option, ls shows directories on top of all
non directory entries, but IMHO symlinks to directories should be handle as
directories as well.
Thanks for the patch, but a change in behavior like that
When using the option --reply=no for mv, it still overwrites the file when it
is not supposed to.
Here is a quick demo:
[EMAIL PROTECTED] ~]# mkdir mvtest
[EMAIL PROTECTED] ~]# cd mvtest/
[EMAIL PROTECTED] mvtest]# mkdir moveto
[EMAIL PROTECTED] mvtest]# echo test file.ext
[EMAIL PROTECTED]
On Feb 12, 2008 1:22 PM, Jim Meyering [EMAIL PROTECTED] wrote:
Steven Schubiger [EMAIL PROTECTED] wrote:
I hacked up a prototype of ls with the possibility of specifying
a format string that currently solely defines the order of items.
Thanks for working on this.
However, before you invest
Pádraig Brady [EMAIL PROTECTED] wrote:
I can't think of any reason I would use `ls --format` over `find -printf`
Ha! Good point. Nor can I. I'll remove the TODO item.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
Steven Schubiger [EMAIL PROTECTED] wrote:
Jim Meyering [EMAIL PROTECTED] wrote:
However, before you invest more time in it, please look at
how GNU find handles its -printf predicate and see if it
is feasible to share parts of that code.
As far as I can tell, most of the logic boils down to
Jim Meyering [EMAIL PROTECTED] wrote:
However, before you invest more time in it, please look at
how GNU find handles its -printf predicate and see if it
is feasible to share parts of that code.
As far as I can tell, most of the logic boils down to insert_fprintf()
in findutils' parser.c.
Eric Blake [EMAIL PROTECTED] wrote:
According to Day on 2/11/2008 8:35 PM:
|
| [ $(ls -A --color ./dir) ] echo Not Empty || echo Empty
|
| the echoed message is always Not Empty, regardless of the fact that
./dir is actually EMPTY. Below is the tested result.
Thanks for the report.
On Feb 12, 2008 2:59 PM, James Youngman [EMAIL PROTECTED] wrote:
On the other hand, refactoring the code would probably only be
worthwhile if the result would not be reused.
Obviously the not there should be removed.
James.
___
Bug-coreutils
Bert Wesarg [EMAIL PROTECTED] wrote:
With the --group-directories-first option, ls shows directories on top of all
non directory entries, but IMHO symlinks to directories should be handle as
directories as well.
Thanks for the patch, but a change in behavior like that
requires some serious
With the --group-directories-first option, ls shows directories on top of all
non directory entries, but IMHO symlinks to directories should be handle as
directories as well.
Regards.
Bert
2008-02-12 Bert Wesarg [EMAIL PROTECTED]
ls --group-directories-first: symlinks to dirs are
Steven Schubiger [EMAIL PROTECTED] wrote:
I hacked up a prototype of ls with the possibility of specifying
a format string that currently solely defines the order of items.
Thanks for working on this.
However, before you invest more time in it, please look at
how GNU find handles its -printf
I hacked up a prototype of ls with the possibility of specifying
a format string that currently solely defines the order of items.
I had to change quite a bit of the underlying code to make it work,
as in, moving most of the routines called by print_long_format() to
functions, that are both used
Thomas Schwinge [EMAIL PROTECTED] wrote:
$ readlink -f a/../a/f
$ echo $?
1
...
readlink (GNU coreutils) 5.97
Why doesn't it resolve the latter case just as the previous ones?
Because there are two symbolic links involved? Or two times the same
one? Strange.
Thanks for the report.
27 matches
Mail list logo
