Blinging out your terminal, adding more colors

I recently installed Arch on my desktop, forsaking Ubuntu.

I still like Ubuntu and all, but it was an old version (Jaunty), too many packages were getting too badly outdated, and the one flaw with Ubuntu is that through bitter experiences I no longer trust dist-upgrades at all.

Arch promised a solution to this, in rolling upgrades. It hasn’t convinced me yet, but having given Ubuntu a chance for little over three years, Arch should get the benefit of a doubt until it does something pants-on-head-crazy at least ;)

One thing (among a whole host) I missed in Arch, which Ubuntu had done for me, was setting up dircolors so that when running the ls command some types of files (determined by their extension) would be colorized differently.

For instance, I quite liked that in Ubuntu, whenever I executed an ls in a directory containing tarballs, they’d all show up with a bright red color instead of the usual bland green.

It made it easier to locate them, which, in theory, would save me time.

So I fired up Firefox and asked Google for

archlinux colorize images and archives in ls

What Google returned was (among others) these two forum-posts:

The first didn’t seem all that useful to me, which was why I went to the other post and found almost all I was looking for. The ~/.dir_colors in the second post didn’t have any TERM line for rxvt, but the first post did, so with a little copying and pasting voilà! Colors! Colors everwhere!

So what you want to be doing is:
a. edit your ~/.bashrc (or whatever shell you’re using) adding:

if [ -f ~/.dir_colors ]; then
    eval `dircolors ~/.dir_colors`

b. read the dir_color manpage to understand how the ~/.dir_colors file should be formatted and what the available color codes are. I.e.:

Attribute codes:
00=none 01=bold 04=underscore 05=blink 07=reverse 08=concealed
Text color codes:
30=black 31=red 32=green 33=yellow 34=blue 35=magenta 36=cyan 37=white
Background color codes:
40=black 41=red 42=green 43=yellow 44=blue 45=magenta 46=cyan 47=white

For instance, would you want files of a certain extension to show up as blinking red text on a black background use: 05;31;40
(you probably don’t want do use that specific combination for anything ;D)

c. go crazy with colors in your ~/.dir_colors, e.g.:

# archives
.tar 01;31
.tgz 01;31
.tar.gz 01;31

# images
.jpg 01;35
.jpeg 01;35
.gif 01;35
.png 01;35


That’s all there is to it really. Changes won’t appear in any existing terminal until you source the .bashrc file but all new terminals will behave “correctly” from the start.

And in closing, a completely unrelated little Arch tip:

If you are trying to get k3b or k9copy to work and it just frakking won’t, you are most likely not part of the group “optical”.

# usermod -a -G optical YourUsernameHere

fixes that (the user added to the optical group would need to log out and in again for changes to take effect).


Tags: , , , , , , ,

6 Responses to “Blinging out your terminal, adding more colors”

  1. Peter says:

    How about putting the following in you .bashrc ?

    alias ls=”ls –color”

  2. Patrik says:

    In my .bashrc there either already was, or I added (my memory if full of fail ;D) alias ls=’ls –color=auto’ which (since my terminal obviously support coloring) should be equivalent to your suggestion. But yes, it was indeed an oversight of me to miss such an easy step to begin sprucing up the terminal ;)

    Thanks for the reminder :)

  3. nummersex says:

    correct me if i’m wrong here, but shouldn’t usermod be executed through sudo? Can’t add yourself to a group you dont have access to, right? /#6

  4. Patrik says:

    Ok, I’ll correct you ;D

    The devil is in the details.
    $ for regular user shell
    # for root shell

    at least that is the impression I have always gotten from various blags online (and from my own shell)
    So you are correct in that one would need superuser powers to add a user to a group.
    And that is exactly what the hash-sign in my command indicate that I have.

    Would you agree with my reasoning?
    Thank you for commenting :)

  5. Peter says:

    @Patrik, interesting observation about the signs.

    I always thought the # sign as a indicator for shell command but with the safety of not executing anything if the user only copy and paste, since the comment feature of the sign, thus preventing the new user from simply copy and paste without understanding.

    As to the root vs other environment and sudo.
    Using sudo is only one way of getting into superuser privileges and in my opinion a rather risky way from a security and user education point of view. Mainly because you tech that it is ok to enter your superuser credentials within a non superuser environment making. This makes the less privileged user just as big target with similar risk as if the user was running as root all the time.

    The sudo is also dependent on the system configuration. Distros like Ubuntu default the first user to have “sudo privileges” and I understand why it in these communities makes sense to prefix privileged commands with sudo for simplicity, but it also makes their users unaware of what really is happening.
    Since the post mentions Arch which is one of the distros that does not come preconfigured with sudo rules it makes more sense here.

    Personally I believe it it one of the basic linux user knowlede to know how to run privileged commands on you system, and find out when it is needed by the fact that the commands does not work otherwise.

  6. Patrik says:

    Hiya :)

    I can’t vouch for the correctness of my observation, but to this day it has held true. I further belive this by observing the behaviour of the \$ sequence inside the PS1 variable set in most bash.bashrc.

    For any user except root (I guess this is based on uid or something other arcane I’ve yet to learn) a dollar sign is shown. The root user on the other hand get the hash sign.

    I do however like the idea that it could reduce copy/paste errors by commenting the command for users not in the know.

    I’ve come to more or less agree with you regarding sudo (especially since ). My using sudo is a legacy from my “Ubuntu roots”, and my continued usage of sudo (in Arch) is clearly a case of convenience forsaking security.

    Thanks for your comment :)