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 _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils