Unable to set LS_COLORS in bash using script

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP





.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;







up vote
-1
down vote

favorite












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



Steps



  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?



Additionally



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



UPDATE



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.







share|improve this question





















  • 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 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 at 10:36
















up vote
-1
down vote

favorite












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



Steps



  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?



Additionally



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



UPDATE



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.







share|improve this question





















  • 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 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 at 10:36












up vote
-1
down vote

favorite









up vote
-1
down vote

favorite











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



Steps



  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?



Additionally



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



UPDATE



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.







share|improve this question













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



Steps



  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?



Additionally



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



UPDATE



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.









share|improve this question












share|improve this question




share|improve this question








edited Jul 28 at 13:14
























asked Jul 27 at 19:26









MyWrathAcademia

1369




1369











  • 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 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 at 10:36
















  • 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 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 at 10:36















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 at 20:05




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 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 at 10:36




that was an example and not the real value of the TERM variable. The real value is much shorter.
– MyWrathAcademia
Jul 28 at 10:36










2 Answers
2






active

oldest

votes

















up vote
1
down vote













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.






share|improve this answer























  • 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 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 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 at 13:38

















up vote
0
down vote













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"





share|improve this answer





















  • 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 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 at 14:13










Your Answer







StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
convertImagesToLinks: false,
noModals: false,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);








 

draft saved


draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f458937%2funable-to-set-ls-colors-in-bash-using-script%23new-answer', 'question_page');

);

Post as a guest






























2 Answers
2






active

oldest

votes








2 Answers
2






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
1
down vote













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.






share|improve this answer























  • 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 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 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 at 13:38














up vote
1
down vote













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.






share|improve this answer























  • 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 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 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 at 13:38












up vote
1
down vote










up vote
1
down vote









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.






share|improve this answer















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.







share|improve this answer















share|improve this answer



share|improve this answer








edited Jul 28 at 13:15


























answered Jul 28 at 11:05









Thomas Dickey

49k583153




49k583153











  • 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 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 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 at 13:38
















  • 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 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 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 at 13:38















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 at 11:15





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 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 at 11:23




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 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 at 13:38




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 at 13:38












up vote
0
down vote













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"





share|improve this answer





















  • 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 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 at 14:13














up vote
0
down vote













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"





share|improve this answer





















  • 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 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 at 14:13












up vote
0
down vote










up vote
0
down vote









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"





share|improve this answer













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"






share|improve this answer













share|improve this answer



share|improve this answer











answered Jul 28 at 9:12









Thomas Zwaagstra

40426




40426











  • 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 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 at 14:13
















  • 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 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 at 14:13















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 at 11:21




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 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 at 14:13




@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 at 14:13












 

draft saved


draft discarded


























 


draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f458937%2funable-to-set-ls-colors-in-bash-using-script%23new-answer', 'question_page');

);

Post as a guest













































































Popular posts from this blog

How to check contact read email or not when send email to Individual?

Displaying single band from multi-band raster using QGIS

How many registers does an x86_64 CPU actually have?