Eric Blake <[EMAIL PROTECTED]> wrote: > Andreas Schwab <schwab <at> suse.de> writes: >> >> I'm using Slackware-current and with ls (GNU coreutils) 6.7 broken >> >> symlinks >> >> are colored in cyan instead of red. what baffles me even more, though, is >> >> that they are colored right with ls -l. any ideas? >> > >> > Yes. Try 6.9, seems to be fixed. >> >> Doesn't look like. It appears to depend on d_type support. > > Does this fix it? I don't have access to a d_type machine myself, to check.
It sure does. Thanks! > While we're at it, what is supposed to be the difference between ORPHAN and > MISSING in dircolors? dircolors.hin only documents ORPHAN, but it looks like > ls special-cases the difference between the two such that ORPHAN always stats, > but MISSING only stats on long listings. MISSING is used in a long listing to color the referent of a dangling symlink, i.e., the nonexistent file the link points to. > diff --git a/src/ls.c b/src/ls.c > index f412dff..c0e332b 100644 > --- a/src/ls.c > +++ b/src/ls.c > @@ -2578,7 +2578,7 @@ gobble_file (char const *name, enum filetype type, > ino_t i > node, > && (type == symbolic_link || type == unknown) > && (dereference == DEREF_ALWAYS > || (command_line_arg && dereference != DEREF_NEVER) > - || color_symlink_as_referent)) > + || color_symlink_as_referent || check_symlink_color)) > /* Command line dereferences are already taken care of by the above > assertion that the inode number is not yet known. */ > || (print_inode && inode == NOT_AN_INODE_NUMBER) I'll apply that as soon as I write a test. _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
