On Sat, Jun 06, 2009 at 09:42:10AM +0200, Kamil Dudka wrote:
> On Saturday 06 of June 2009 06:13:04 Joshua Rodman wrote:
> > Buh buh buh -- the recommended sed does not work.
>
> Thanks for pointing this out. Which recommendation did you follow? The one
> in the NEWS file? Did you try exactly this?
>
> $ 'eval `dircolors | sed s/hl=[^:]*:/hl=:/`
> Which shell are you using?
I put that line, minus the initial tick (') in my bashrc, but I thought
the demo would be clear that the hl sed cannot work since there is no hl
for it to match.
I am using bash, as I meant the working directory to hint.
Perhaps I should have added
jrod...@calufrax:~/rc/bash >echo $SHELL
/bin/bash
This indeed the example from the NEWS file, which was the only
information I could find on disabling the feature.
> > jrod...@calufrax:~/rc/bash >dircolors ~/rc/dir_colors |grep hl # no hl
>
> Yes, because your file ~/rc/dir_colors does not contain any color definition
> for hard link. Try to add the following line to that file, it should solve
> your problem:
>
> HARDLINK 00
Given the example sed which sets 'hl=' as an element of the LS_COLORS,
combined with the lack of definition in dir_colors for a color-sequence
that is empty, I presumed that the empty color-sequence was a special
case, and that 0 would set the coloring to be the terminal default, not
whatever the color might otherweise be.
Therefore, I tried various inventions to convey an empty color sequence
in the dir_colors file, without success.
Because of this point of confusion, I would recommend the use hl=00 as
the example as a minimum step. Ideally the meaning of an empty color
sequence would additionally be documented or the support for such a
sequence deprecated and/or removed from the code.
I went ahead and tried out your suggestion, and it is effective.
Multi-Hardlink files with colored extensions are now displayed as
expected.
> > I'm unclear whether dir_colors will sometimes spit out an hl value.
> > Having a colorization occur that isn't even in LS_COLORS is unfortunate.
>
> I think we should improve documentation a bit. It is not only about hard
> links. Some people may also want to disable file capabilities highlighting,
> etc. P?draig, what do you think?
I still think that this behavior is incorrect, because it is not
helpful.
All files are hard links. While files with more than one link are
sufficiently unsual to impair discovery of the meaning, they're also
sufficiently normal to not merit special attention.
Contrarily, symbolic links behave differently and must be treated
differently with some tools, so that coloring seems useful. broken
symbolic links are definitely a case worth noting as exceptional and
broken. Both of these situations are quite obvious. Symbolic links show
themselves in any ls -l listing, and the broken case gives you errors.
The hard link situations requires knowing to look for and comprehend
parts of the ls output that many do not understand.
It's a look-at-me feature for things that don't need to be looked at,
applied to all users who very well may have no need to care about nor
even ability to understand what is being identified.
That's all opinion, of course, but I think colorizing hard links when no
hl is in LS_COLORS is a strong misfeature. Even after finding out about
the feature by grovelling through release notes and such, I still could
not understand how it was operating, since my configuration explicitly
lacked the setting. If colorizing files that have multiple hard links
is really the right default, I believe the distribution should take care
of that in /etc/DIRCOLORS or the like.
Parting gripes: HARDLINK is confusing, since as above, all files are
hard links. MULTIHARDLINK perhaps?
-josh
_______________________________________________
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
