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 repo
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] mvt
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 explicit)
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 symlinks-t
-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
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
/home/thomas/tmp/a-long/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
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 s
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 s
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 th
-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
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 f
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
req
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
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
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
http://lists.gnu.org/mail
I can't think of any reason I would use `ls --format` over `find -printf`
Pádraig.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
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 bo
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.
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 di
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 b
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
http://lists.gnu.org/mailman/listinfo/bu
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
"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 c
[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 fi
28 matches
Mail list logo
