On Friday 20 of March 2009 12:15:34 Pádraig Brady wrote: > Wes Morgan wrote: > > The new "hard link" highlighting would be nicer if it was optional. I > > have lots of files with an "original" name that are also hard links to a > > canonicalized version in another directory hierarchy. Instead of showing > > the original coloring based on the extension, they show the hard link > > coloring. Perhaps a special code for dircolors that tells "ls" to ignore > > a class of highlighting and continue searching for another match. > > That change was made recently: > http://lists.gnu.org/archive/html/bug-coreutils/2008-10/msg00172.html > Kamil indicated in that bug report that existing colors should take > precedence over the hardlink color. This is the case for executable files > for example, but not files whose color depends on name.
Only security-important attributes are preferred before hard links. In any other cases the behavior is equivalent to symbolic link. I propose a one-line patch like this: http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=f3f1ccfd871ee395e7fafc051c1b7dedb39fdfc9 With the patch user can choose to not highlight hardlinks in his own profile. IMHO it's not common to distribute Linux (or any other systems) with tons of hard-linked files. The hard links are mostly created by user. It should be visible at first glance if the file is hard-linked unintentionally (e.g. by omitting -s option of ln). The patch will be ready next week. Also any other ideas are welcome. Kamil _______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
