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.

  • @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. – 0xC0000022L Feb 5 '13 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? – unperson325680 Nov 5 '15 at 17:39

Do this:

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

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


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

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

git tag --contains 1e48b1fee5fa2ad2d1802771eafbfcddb38a24cb

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.

  • Thanks a lot. Spot on. The only trouble right now is how to do this conditionally depending on the version of coreutils :) – 0xC0000022L Feb 5 '13 at 1:28
  • @0xC0000022L Updated! – gertvdijk Feb 5 '13 at 1:36

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"

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.

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.