14

Currently I have a command-line application in C called btcwatch. It has a -C option that it can receive as an argument that compares the current price of Bitcoin with a price that was stored beforehand with -S. Example output with this option is:

$ btcwatch -vC  # -v = verbose
buy: UP $ 32.000000 USD (100.000000 -> 132.000000)
sell: UP $ 16.000000 USD (100.000000 -> 116.000000)

The dilemma is whether to use colour for the UP or DOWN string (green and red, respectively). Most command-line applications I know of (apart from git) stay away from colour in their output. In my desire for btcwatch to look and be quite "standard" (use of getopt, Makefiles, etc), I'm not sure if colour would look out of place in this situation.

  • git has color in its output? Have I just not yet run across the particular commands that do that? – Izkata Nov 2 '13 at 3:28
  • Great answers below. But always remember about coloring that a non-trivial portion of your users will not be able to distinguish the difference between red and green. – Ross Patterson Nov 2 '13 at 10:20
  • Izkata: git diff, git pull, etc. – Marco Scannadinari Nov 2 '13 at 13:08
  • @Izkata Yes, git can be configured to use color in its output. – Andres F. Nov 2 '13 at 15:16
  • @marcoms Those don't have color output for me. I've done no special configurations to enable it, though. – Izkata Nov 2 '13 at 21:44
21

The appropriate thing to do is to make the coloring optional, default to "off" and control it via a command-line flag. That way, people who don't like it or whose terminal doesn't support it aren't affected, people who like it can use it, and people who really, really like it can define an alias or shortcut to predefine the option. Everybody's happy.

  • 5
    This is the functionality of ls (the ls --color option is required to turn it on). – user40980 Nov 1 '13 at 18:59
  • @MichaelT: Really? I guess it depends on the distribution you use. The output (almost) always has colour and I never specify --color. – FrustratedWithFormsDesigner Nov 1 '13 at 19:18
  • 1
    @FrustratedWithFormsDesigner BSD flavor. /bin/ls is plain, /bin/ls -G is colored (though if you have CLICOLOR defined in the environment, that option acts as default on). In gnu influenced distributions, one sees --color and its associated environment variables. – user40980 Nov 1 '13 at 19:32
  • 1
    Great answer to "Should color be mandatory or not", less so for "when is it appropriate" :) – Michael Durrant Nov 1 '13 at 21:37
  • 3
    @FrustratedWithFormsDesigner On ubuntu, for example, alias ls='ls --color=auto' comes in the default .bashrc (or if it doesn't anymore, it did somewhere around 8.04 give or take a year, and I've just carried my .bashrc across installations) – Izkata Nov 2 '13 at 3:30
9

I would consider it appropriate to use color when:

  • There are 'groups' of items and color groups will help visually group the items.

  • There are set(s) of 'label:value' fields and you want the labels (or values) to stand out.

  • There are items that would benefit from being shown in red/green, e.g. stop/go, good/bad, etc.

  • Most of the information is background but one key item should stand out.

5

One other major factor to consider is that coloring, depending on platform, can add character escape sequences. For builds on those platforms, If the current/default mode is to output colour, it is customary to detect if the program output is a PIPE and stripping colour if that is the case.

This is so that the color escape sequences do not throw off downstream programs that read it's output.

  • good point, I suppose implementing a --colour (or --no-colour) option will be more friendly to such programs – Marco Scannadinari Nov 2 '13 at 13:10

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.