Is there any way to colour coordinate symlinks/softlinks based on where they're linked, or maybe by who they 'belong' to (similarly to colouring the output of ls for example)?

To give you an example of why I think this might be neat, I have an account on a server at work, and I can install software in to my homedirectory, and make softlinks to directories currently within my path - but I cannot link in /usr/local/bin for example, as I'm not a sudoer. So I can envisage a situation where a program I link, ends up with the same handle in the PATH as one installed centrally...

Hopefully this hypothetical example will illustrate what I mean: Lets say I link some program I installed in ~/newprogram/ to the directory ~/Apps/ which I've already set to exist in my PATH.

If I want to call the new program and I do so with autocomplete, perhaps there exists already an application installed by the admins which just so happens to use the same symlink name (if this is even possible I haven't checked). When I tab to autocomplete a substring of the program name, I should be presented with all the various options - lets say it looks something like this:

user@server:~$ newprog          #double tab:
newprog       newprogram       newprogram

So there are multiple matches, and 2 with the exact same shortcut/program name in the path either linked or directly. And lets say one is 'mine' and the other is from /usr/local/bin.

Could each occurence of "newprogram" be coloured such that the newprogram which refers to my symlinked one is one colour, and the other occurence of "newprogram" is coloured to indicate it is present in some other directory in the PATH (e.g. /usr/local/bin/)?


Sorry yes, forgot to mention, this would be on Ubuntu for this specific server.


Much of the colouration is being done through my .bashrc which is looking at /usr/bin/dircolors but that only affects the output of my executed commands (ls etc.) and not the behaviour of autocompletes.

This is what I have in my .bashrc at the moment, which I admit has been shamelessly stolen from some "show us your bashrc" type thread somewhere.

# uncomment for a colored prompt, if the terminal has the capability; turned
# off by default to not distract the user: the focus in a terminal window
# should be on the output of commands, not on the prompt

if [ -n "$force_color_prompt" ]; then
    if [ -x /usr/bin/tput ] && tput setaf 1 >&/dev/null; then
        # We have color support; assume it's compliant with Ecma-48
        # (ISO/IEC-6429). (Lack of such support is extremely rare, and such
        # a case would tend to support setf rather than setaf.)

if [ "$color_prompt" = yes ]; then
    PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
unset color_prompt force_color_prompt

# enable color support of ls and also add handy aliases
if [ -x /usr/bin/dircolors ]; then
    test -r ~/.dircolors && eval "$(dircolors -b ~/.dircolors)" || eval "$(dircolors -b)"
    alias ls='ls -h --color=auto'
    #alias dir='dir --color=auto'
    #alias vdir='vdir --color=auto'
    alias grep='grep --color=auto'
    alias fgrep='fgrep --color=auto'
    alias egrep='egrep --color=auto'


Example of changed behaviours of symlinks: enter image description here

raxml and prunier are symlinks that were previously blue.

However the autocomplete output above remains uncoloured for any symlink (tf as an example)

  • What OS are you using? – Satō Katsura Jul 5 '16 at 13:54
  • Oh yeah forgot to mention that. Edited question. This particular server is running Ubuntu 12.04.2 LTS – Joe Healey Jul 5 '16 at 14:02
  • Autocompletion runs ls to find out what to complete. – Satō Katsura Jul 5 '16 at 14:51
  • I've modified the .dircolors file successfully and it has changed the behaviour of my symlinks, so that's half the battle. However, none of my autocomplete output is coloured still...see example image in newest edit.. – Joe Healey Jul 5 '16 at 20:04

GNU ls gives you a choice between coloring files by their type or (if a given type is not colored) by a pattern. That is done by the dircolors program which has a built-in database of types, patterns and colors. ls does not care about the directory path itself. The aspect of "where they refer to" is not easily done with that program. Symbolic links versus regular files is easy.

You can modify the database most easily by printing it to a file using

dircolors -p >myfile

Depending on the system, your shell startup may look for /etc/DIRCOLORS). After editing it, use dircolors to assign a value to LS_COLORS:

eval 'dircolors myfile'

The dir_colors configuration manual describes the database, and mentions the feature you may want to change:

LINK color-sequence
Specifies the color used for a symbolic link.

or in the printed (default) database

LINK 01;36 # symbolic link. (If you set this to 'target' instead of a
 # numerical value, the color is as for the file pointed to.)

The example combines bold and cyan. You can use a different color combination by modifying that line. (By the way, the dir_colors manual page refers to "bright": ISO 6429 says bold).

bash does not use ls for autocompletion, and ls coloring is separate from bash. However, an equivalent feature was added in 2014 to bash which uses the same LS_COLORS variable to tell what colors can be displayed. That is a feature of bash 4.3, as shown in the bash manual:

If set to `on', Readline displays possible completions using different colors to indicate their file type. The color definitions are taken from the value of the LS_COLORS environment variable. The default is `off'.

To use it, add

set colored-stats on

to your .inputrc file.

Further reading:

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.