7

How can I colorize hardlinks myself? Turns out on an old Ubuntu 10.04 I have, this happens by default (same .bashrc and .profile in use), whereas on the newer Ubuntu 12.04 it doesn't.

This is the output on Ubuntu 10.04 (the one I desire):

Having the colored output for hardlinked files

And this is the output on Ubuntu 12.04: Missing the colored output for hardlinked files

The relevant file is .vimrc, however, .viminfo is an ordinary file with link count 1, in contrast to the hardlinked .vimrc.

Of course the fact that GNU coreutils uses texinfo pages instead of man pages doesn't make things easier. I found this here, but it doesn't refer to the case I am looking for.

TL;DR: how to achieve coloring hardlinked (as in: link count > 1) files the way I like in various Ubuntu versions.

2
  • @gertvdijk: please, by all means write this up as an answer. Even though it is not the answer I would have liked, this is certainly an authoritative answer on the topic and solves the mystery. Thanks. Feb 5, 2013 at 1:16
  • Isn't finding hardlinks a very expensive operation? Do some filesystems provide a reverse lookup or at least a count for links per inode?
    – mike3996
    Nov 5, 2015 at 17:39

2 Answers 2

10

Do this:

LS_COLORS="mh=44;37" ls -l

And you may edit your ~/.profile to change LS_COLORS accordingly.

Background

This feature was enabled as default in 2008 has been disabled by default in 2009. Somehow the freeze for Ubuntu 10.04 was exactly in between those moments.

Using the Git repository of coreutils I see that the commit to revert automatic colourization has been in since version 7.5:

git tag --contains 0df338f6719ec2bcf1e1dea2d8b12dc66daf8a1e
v7.5
v7.6
[...]

In versions before 7.1 there seems no upstream maintained support for this:

git tag --contains 1e48b1fee5fa2ad2d1802771eafbfcddb38a24cb
v7.1
v7.2
[...]

The source file multihardlink.sh, lead me to the exact LS_COLORS value to enable it again.

You may want to reopen LP Bug #123423.

3
2

Based on gertvdijk's answer, I came up with the following snippet, which suits my needs:

if [[ -e "/etc/debian_version" ]] && type dircolors > /dev/null 2>&1; then
    command dircolors|command grep -q 'hl=' && export LS_COLORS="ln=01;36:hl=00;36"
    command dircolors|command grep -q 'mh=' && export LS_COLORS="ln=01;36:mh=00;36"
fi

Edit: I actually had to rewrite the snippet (see edit history).

Turns out that ls swallows the error output concerning LS_COLORS when piping it. At least I couldn't grep for it, neither with 2>&1 nor without. Hence the changes. We check for dircolors to be available. If it is, it's expected to output a snippet of shell code (Bourne shell compatible by default) that contains the defaults for the various recognized file types. So we check for hl= or mh= respectively in the output of dircolors. This way we can detect which is expected by ls and export LS_COLORS accordingly. It may be safer to grep for :hl= and :mh= respectively to rule out the possibility for file extensions ending in hl or mh and matching our condition.

The above colors are light cyan on black for soft links and a darker cyan on default black for hard links.

You can vary the top-level condition, of course. I am currently only setting it on Debian/Ubuntu, because I have no time to test it on older RHEL/CentOS systems at the moment.

NB: the invocations via command are to work around potential aliases/functions with the same names as the tools we try to use here.

1
  • dircolors is the way to configure this, yes! :)
    – gertvdijk
    Feb 5, 2013 at 15:58

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .