I am trying to set the LS_COLORS environment variable using a launcher script. However this variable is not being set.


  1. Downloaded LS_COLORS to ~/.dircolors

  2. Added TERM=xterm-newTerminalEmulator where all the other TERM variables were defined in .dircolors

  3. Created a launcher script in ~/bin/ls

  4. Populated this launcher script with the shebang, eval to pass the strings in bracket as a command to the shell and exec to replace all processes with just the ls process:

    #!/bin/sh eval $(dircolors -b ~/.dircolors) exec /bin/ls "$@"

  5. Made the ~/bin/ls file executable.

The man page for dir_colors says

Usually, the file used here is /etc/DIR_COLORS and can be overridden by a .dir_colors file in one's home directory.

Would this be why its not working, considering only the system wide /etc/DIR_COLORS script is being used?


I also have an alias for ls set as alias ls = "ls --color" and echo $LS_COLORS shows nothing.

System specifications are: fedora28 and bash


I got this working, but I am not satisfied with the colors. The defaults are more intuitive, not only this but LS_COLORS does not differentiate between executables and symlinks which is a deal breaker.

  • likely your TERM variable isn't xterm-newTerminalEmulator (and if it is, likely it's longer than the allowed length for the ls program). – Thomas Dickey Jul 27 '18 at 20:05
  • that was an example and not the real value of the TERM variable. The real value is much shorter. – MyWrathAcademia Jul 28 '18 at 10:36

The documentation's vague, but setting the environment variable isn't enough: you need the --color option. Without an option value, that corresponds to --color=always (most people expect --color=auto, which suppresses the color in a pipe).

You can see how the --color option is treated in the source-code for ls, in particular the variable print_with_color and its interaction with LS_COLORS.

For what it's worth, the eval command is needed to evaluate the export command returned by dircolors, and that environment variable is preserved across the exec. Your example (with the added --color option) worked for me with bash and dash.

  • Are you saying that if I want LS_COLORS to work then I have to set the --color option to auto? I set an alia for --color exactly for the reason you mentioned - to allow colors when piped to less. – MyWrathAcademia Jul 28 '18 at 11:15
  • I already set the --color option in an alias as shown above. Did I mention that /bin is a symlink and not a directory? Could this be the problem? – MyWrathAcademia Jul 28 '18 at 11:23
  • Whether /bin is a symlink or not doesn't matter. Other ls is aliased to have the --color option; you'd notice this difference in scripts which don't inherit aliases from the parent (only environment variables would be inherited). – Thomas Dickey Jul 28 '18 at 13:38

You're running dircolors in a subshell, so the changes only apply within the subshell.

The subshell is $( ... )

Try this instead...

alias ls="dircolors -b ~/.dircolors && ls"
  • I am not sure how using the command substitution runs dircolors in a subshell. As far as I know that is what the command bash is for. I rather not set an alias for this because I also have the exec /bin/ls command. A launcher script is the right way to do it but something seems to be missing. – MyWrathAcademia Jul 28 '18 at 11:21
  • @mywrath everything within the parenthesis of the command substitution is run under a subshell, which is a copy of the parent environment. So the output is used for the value of the "variable" but no other side effects escape – Thomas Zwaagstra Jul 28 '18 at 14:13

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.