bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] ls --group-directories-first: symlinks to dirs are dirs too


From: Linda Walsh
Subject: Re: [PATCH] ls --group-directories-first: symlinks to dirs are dirs too
Date: Tue, 12 Feb 2008 18:13:23 -0800
User-agent: Thunderbird 2.0.0.9 (Windows/20071031)

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-to-dirs.
----
        This is not exactly true.  When running under said Proprietary-OS,
directories are grouped first, but ".lnk" files -- which are explorer's
idea of links are grouped with files.

        I don't know if I agree with explorers choice, however, since
when I've created a symlink to a directory, I'd 'like' to see it with
the directories, as I would  "want" to treat it as a directory, for
"visual scanning" purposes.  Additionally, on explorer, a visual cue
of a little arrow in the lower left of the icon is usually visible.

        In *nix, though, with classifier-suffixes on, a normal
ls will show a "@" at the end of a symlink, even though that symlink
might point to an executable that would normally be tagged with a "*".

        Thus, to be consistent, are you wanting to look at the "type"
of what the symlink points to ("-L"), or the directory entry itself
(which would be a symlink).

        To have "symlinks-to-dirs" be treated as dirs (in absence of
"-L", but then not have other files be classified as their underlying
type, seems inconsistent).


| Currently there is no test for this option, even Francesco has posted
| one which also consider symlinks, and the documentation for this options
| doesn't mention symlinks too. So, IMHO there is no change in documented
| behavior with this patch.
----
        It would be inconsistent with the proprietary OS's behavior
after which the option was modeled.  Is that logical?

        Believe me, I understand wanting to see symlinks to dirs grouped
with dirs, but this isn't how it's done in explorer and doesn't seem
consistent.  I wouldn't mind a "treat-symlinks-to-dirs-as-dirs" type
option, but that seems awfully esoteric.  Why should symlinks to dirs
be treated differently from symlinks to non-dirs? ....

        If I use classifier suffixes (as my aliases always enable), then
how would a symlink->dir be flagged?   "dir/" or "dir@"?


        HEY---*light-bulb*.  You can have two types of links to directories
and I don't know if there is any behavioral difference, BUT...it seems
I am able to have:
ln -s dir/ symdir
   and
ln -s dir symdir

Perhaps it would be "logical" (if anyone think I'm daft, I'm sure they'll
speak up)...to group symlinks to names that end in "/" be grouped with
dirs, while symlinks to names w/o "/" are treated same as now...?

It's slightly "obscure", but a rational for the difference in behavior
could be logically made? (or am I delusional?)....

A possible slight "gotcha"...with the embedded "/" at the end to indicate
a dir, then the classifier char creates a double "//".  Not a major
problem in my opinion, but it can look odd:

ish:/tmp> ln -s /tmp foo
ish:/tmp> ln -s /tmp/ foo2
ish:/tmp> ll foo*
lrwxrwxrwx 1 4 2008-02-12 18:08 foo -> /tmp/
lrwxrwxrwx 1 5 2008-02-12 18:09 foo2 -> /tmp//
ish:/tmp> ls foo*
foo@  foo2@

----------

-Linda




reply via email to

[Prev in Thread] Current Thread [Next in Thread]