Unable to set LS_COLORS in bash using script
Clash 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
Downloaded LS_COLORS to ~/.dircolors
Added TERM=xterm-newTerminalEmulator where all the other TERM variables were defined in .dircolors
Created a launcher script in ~/bin/ls
Populated this launcher script with the shebang,
eval
to pass the strings in bracket as a command to the shell andexec
to replace all processes with just thels
process:#!/bin/sh
eval $(dircolors -b ~/.dircolors)
exec /bin/ls "$@"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.
bash shell-script colors exec settings
add a comment |Â
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
Downloaded LS_COLORS to ~/.dircolors
Added TERM=xterm-newTerminalEmulator where all the other TERM variables were defined in .dircolors
Created a launcher script in ~/bin/ls
Populated this launcher script with the shebang,
eval
to pass the strings in bracket as a command to the shell andexec
to replace all processes with just thels
process:#!/bin/sh
eval $(dircolors -b ~/.dircolors)
exec /bin/ls "$@"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.
bash shell-script colors exec settings
likely yourTERM
variable isn'txterm-newTerminalEmulator
(and if it is, likely it's longer than the allowed length for thels
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
add a comment |Â
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
Downloaded LS_COLORS to ~/.dircolors
Added TERM=xterm-newTerminalEmulator where all the other TERM variables were defined in .dircolors
Created a launcher script in ~/bin/ls
Populated this launcher script with the shebang,
eval
to pass the strings in bracket as a command to the shell andexec
to replace all processes with just thels
process:#!/bin/sh
eval $(dircolors -b ~/.dircolors)
exec /bin/ls "$@"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.
bash shell-script colors exec settings
I am trying to set the LS_COLORS environment variable using a launcher script. However this variable is not being set.
Steps
Downloaded LS_COLORS to ~/.dircolors
Added TERM=xterm-newTerminalEmulator where all the other TERM variables were defined in .dircolors
Created a launcher script in ~/bin/ls
Populated this launcher script with the shebang,
eval
to pass the strings in bracket as a command to the shell andexec
to replace all processes with just thels
process:#!/bin/sh
eval $(dircolors -b ~/.dircolors)
exec /bin/ls "$@"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.
bash shell-script colors exec settings
edited Jul 28 at 13:14
asked Jul 27 at 19:26
MyWrathAcademia
1369
1369
likely yourTERM
variable isn'txterm-newTerminalEmulator
(and if it is, likely it's longer than the allowed length for thels
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
add a comment |Â
likely yourTERM
variable isn'txterm-newTerminalEmulator
(and if it is, likely it's longer than the allowed length for thels
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
add a comment |Â
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.
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 toless
.
â 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. Otherls
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
add a comment |Â
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"
I am not sure how using the command substitution runs dircolors in a subshell. As far as I know that is what the commandbash
is for. I rather not set an alias for this because I also have theexec /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
add a comment |Â
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.
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 toless
.
â 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. Otherls
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
add a comment |Â
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.
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 toless
.
â 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. Otherls
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
add a comment |Â
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.
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.
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 toless
.
â 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. Otherls
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
add a comment |Â
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 toless
.
â 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. Otherls
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
add a comment |Â
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"
I am not sure how using the command substitution runs dircolors in a subshell. As far as I know that is what the commandbash
is for. I rather not set an alias for this because I also have theexec /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
add a comment |Â
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"
I am not sure how using the command substitution runs dircolors in a subshell. As far as I know that is what the commandbash
is for. I rather not set an alias for this because I also have theexec /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
add a comment |Â
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"
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"
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 commandbash
is for. I rather not set an alias for this because I also have theexec /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
add a comment |Â
I am not sure how using the command substitution runs dircolors in a subshell. As far as I know that is what the commandbash
is for. I rather not set an alias for this because I also have theexec /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
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
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
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
likely your
TERM
variable isn'txterm-newTerminalEmulator
(and if it is, likely it's longer than the allowed length for thels
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