Re: [PATCH] ls --group-directories-first: symlinks to dirs are dirs too
Eric Blake [EMAIL PROTECTED] wrote: ... This point I can agree with. --group-directories-first is relatively new, and since it is currently silent about behavior on links, I have no problem with changing that behavior; however, I would insist that if we make a change, we add test cases and documentation to lock in that behavior for the future. Yes. If someone were to prepare a complete patch, (i.e., one that I can simply git pull ... or apply with git am, updating NEWS, coreutils.texi, and ls.c's usage (to adjust ls' --help)) that would make a fine point for further discussion. Code speaks more loudly than words. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] ls --group-directories-first: symlinks to dirs are dirs too
Linda Walsh wrote: 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? Forget (cough) the proprietary OS... Konqueror treats symlinks like the files they point to, i.e. symlinks-to-dirs are sorted with dirs. Symlinks-to-other are treated like other as well, though, which I think is what you were saying in the bit I snipped. So +1 for ls grouping symlinks-to-dirs with dirs. If I use classifier suffixes (as my aliases always enable), then how would a symlink-dir be flagged? dir/ or dir@? How about 'dir/@'? I guess we'd do all this with --dereference-and-show or something (unless we'd agree to change --dereference). 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...? Um... I for one don't think so. -- Matthew A pool hall put up a sign in their front window that read: Profound language prohibited within. I could just imagine some people discussing the meaning of life and being told to take it outside. -- Scott Adams ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] ls --group-directories-first: symlinks to dirs are dirs too
-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 (still in the patch tracker): I'm not sure if the current state of things is more from Francesco's code or mine, but I do remember the conversation: | | Your patch does not take into account what behavior should be used | with symlinks to dirs - are they grouped with directories, or with | files, or does it depend on other options (such as -L)? | | And indeed a -L with --group-directories-first does sort symlinks to | directories like directories. But they don't look like symlinks anymore. | | Anyway, this fact was not really discussed, Francesco decided that | symlinks to directories are non-directories and no one objected. 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. | | 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. This point I can agree with. --group-directories-first is relatively new, and since it is currently silent about behavior on links, I have no problem with changing that behavior; however, I would insist that if we make a change, we add test cases and documentation to lock in that behavior for the future. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHskaa84KuGfSFAYARAqbqAKClDoy+4iLwce0cRZEq4hiCuzeJ8gCfb/EG rSOmEJ1fl7+zVyjJ9DDQ2Sk= =PtGu -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] ls --group-directories-first: symlinks to dirs are dirs too
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
Re: [PATCH] ls --group-directories-first: symlinks to dirs are dirs too
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 requires some serious justification. I read the thread in the mail archive. Eric Blake questioned the symlink behavior in the first reply (still in the patch tracker): Your patch does not take into account what behavior should be used with symlinks to dirs - are they grouped with directories, or with files, or does it depend on other options (such as -L)? And indeed a -L with --group-directories-first does sort symlinks to directories like directories. But they don't look like symlinks anymore. Anyway, this fact was not really discussed, Francesco decided that symlinks to directories are non-directories and no one objected. 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. Therefor I change this to an RFC, to further discuss this question. Regards Bert ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] ls --group-directories-first: symlinks to dirs are dirs too
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 justification. It'd be slightly easier if you were proposing a new option, but, for ls, even that is problematic, since there are already so many. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[PATCH] ls --group-directories-first: symlinks to dirs are dirs too
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 dirs too.
src/ls.c (is_symlink_to_directory): New function.
(DIRFIRST_CHECK): Use it.
---
src/ls.c | 17 +++--
1 files changed, 15 insertions(+), 2 deletions(-)
diff --quilt old/src/ls.c new/src/ls.c
--- old/src/ls.c
+++ new/src/ls.c
@@ -2849,10 +2849,21 @@ static bool
is_directory (const struct fileinfo *f)
{
return f-filetype == directory || f-filetype == arg_directory;
}
+/* Return true if F is a symlink that refers to a directory. */
+static bool
+is_symlink_to_directory (const struct fileinfo *f)
+{
+ return (f-filetype == symbolic_link
+ f-linkname
+ f-linkok
+ f-stat_ok
+ S_ISDIR (f-linkmode));
+}
+
/* Put the name of the file that FILENAME is a symbolic link to
into the LINKNAME field of `f'. COMMAND_LINE_ARG indicates whether
FILENAME is a command-line argument. */
static void
@@ -2992,12 +3003,14 @@ typedef int (*qsortFunc)(V a, V b);
The do { ... } while(0) makes it possible to use the macro more like
a statement, without violating C89 rules: */
#define DIRFIRST_CHECK(a, b)\
do\
{ \
- bool a_is_dir = is_directory ((struct fileinfo const *) a); \
- bool b_is_dir = is_directory ((struct fileinfo const *) b); \
+ bool a_is_dir = is_directory ((struct fileinfo const *) a) \
+ || is_symlink_to_directory ((struct fileinfo const *) a); \
+ bool b_is_dir = is_directory ((struct fileinfo const *) b) \
+ || is_symlink_to_directory ((struct fileinfo const *) b); \
if (a_is_dir !b_is_dir)\
return -1; /* a goes before b */\
if (!a_is_dir b_is_dir)\
return 1; /* b goes before a */\
} \
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
