Re: wrong color for broken symlinks

[Jim Meyering]

Eric Blake <address@hidden> 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.