No colored output with --login option in bash
Clash Royale CLAN TAG#URR8PPP
up vote
1
down vote
favorite
I donâÂÂt have colored output from bash tools. And itâÂÂs really inconvenient.
(Btw, I do have colors in bash
itself, e.g. colored prompt).
I noticed when I run /usr/bin/bash
, colors come back. (However, I don't have my profile settings such as aliases and paths).
I can see the only difference here: --login
flag. I think the reason of the problem lays in config files that bash loads at the start with --login
flag.
However, what can it be?
bash
add a comment |Â
up vote
1
down vote
favorite
I donâÂÂt have colored output from bash tools. And itâÂÂs really inconvenient.
(Btw, I do have colors in bash
itself, e.g. colored prompt).
I noticed when I run /usr/bin/bash
, colors come back. (However, I don't have my profile settings such as aliases and paths).
I can see the only difference here: --login
flag. I think the reason of the problem lays in config files that bash loads at the start with --login
flag.
However, what can it be?
bash
Most likely related to theTERM
environment variable.
â Satà  Katsura
Oct 14 '17 at 8:08
1
=xterm in both cases
â zhekaus
Oct 14 '17 at 8:14
add a comment |Â
up vote
1
down vote
favorite
up vote
1
down vote
favorite
I donâÂÂt have colored output from bash tools. And itâÂÂs really inconvenient.
(Btw, I do have colors in bash
itself, e.g. colored prompt).
I noticed when I run /usr/bin/bash
, colors come back. (However, I don't have my profile settings such as aliases and paths).
I can see the only difference here: --login
flag. I think the reason of the problem lays in config files that bash loads at the start with --login
flag.
However, what can it be?
bash
I donâÂÂt have colored output from bash tools. And itâÂÂs really inconvenient.
(Btw, I do have colors in bash
itself, e.g. colored prompt).
I noticed when I run /usr/bin/bash
, colors come back. (However, I don't have my profile settings such as aliases and paths).
I can see the only difference here: --login
flag. I think the reason of the problem lays in config files that bash loads at the start with --login
flag.
However, what can it be?
bash
asked Oct 14 '17 at 8:06
zhekaus
11315
11315
Most likely related to theTERM
environment variable.
â Satà  Katsura
Oct 14 '17 at 8:08
1
=xterm in both cases
â zhekaus
Oct 14 '17 at 8:14
add a comment |Â
Most likely related to theTERM
environment variable.
â Satà  Katsura
Oct 14 '17 at 8:08
1
=xterm in both cases
â zhekaus
Oct 14 '17 at 8:14
Most likely related to the
TERM
environment variable.â Satà  Katsura
Oct 14 '17 at 8:08
Most likely related to the
TERM
environment variable.â Satà  Katsura
Oct 14 '17 at 8:08
1
1
=xterm in both cases
â zhekaus
Oct 14 '17 at 8:14
=xterm in both cases
â zhekaus
Oct 14 '17 at 8:14
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
1
down vote
I noticed when I run /usr/bin/bash, colors come back. (However, I don't have my profile settings such as aliases and paths).
Apparently the commands that set those things up are only run for non-login shells.
Interactive login shells use different startup scripts from other interactive shells.
The commands that set up colored output are probably in the .bashrc
file in your home directory, or in the systemwide /etc/bash.bashrc
. Commands from those files are run for interactive shells that are not login shells, but they are not run from interactive login shells unless a command in a different startup script sources .bashrc
. You should check those files.
When bash
starts as a login shell, it runs commands from /etc/profile
as well as the first of .bash_profile
, .bash_login
, and .profile
that exists in your home directory. Run man bash
for details.
Commands in "profile" files run even in noninteractive login shells for which you likely don't want to set up colorization, and where doing so might even produce errors. In particular, most desktop environments run commands from your .profile
file. So if you add commands for colorization into a "profile" file, you should consider making it run only in interactive shells. Furthermore, some of your commands should only be run in bash
but not in other shells, and you should make sure that is still the case (see below).
One way to determine if a shell is interactive is to check if the PS1
prompt variable exists and is nonempty. You can put this command after all the commands in a "profile" file that you want run even for noninteractive login shells, but before any commands you want run in interactive shells:
[ -z "$PS1" ] && return
Sometimes the interactivity check could be in the "rc" file.
In some operating systems, including Debian and Ubuntu, the default .profile
(copied from /etc/skel/
when a user account is created) sources--that is, runs all commands from--.bashrc
. Similarly, /etc/profile
sources /etc/bash.bashrc
. Not all operating systems where bash
is the default shell do this, though. Probably your system does not.
In those systems, the default .bashrc
and /etc/bash.bashrc
have a line like that at the top before any other commands. Specifically, /etc/bash.bashrc
has that line exactly, while .bashrc
checks if the shell is interactive in a different way:
case $- in
*i*) ;;
*) return;;
esac
This works because an interactive bash
shell has an i
in the special parameter $-
. I mention it mainly in case you prefer to check in that way.
Sometimes it can make sense to conditionally source an "rc" from a "profile."
Depending on your situation, you might want--for example--to make whichever of the "profile" files in your home directory is being used source .bashrc
, as Debian does. I cannot advise you to do this because it depends on what you actually have in all those files. But the way Debian and Ubuntu do it is like this:
# if running bash
if [ -n "$BASH_VERSION" ]; then
# include .bashrc if it exists
if [ -f "$HOME/.bashrc" ]; then
. "$HOME/.bashrc"
fi
fi
Commands in .bashrc
are usually only capable of being run by bash
, so you should not set things up so other shells will run them inadvertently. That' what the code above achieves. In .bash_profile
or .bash_login
, you can have just . "$HOME/.bashrc"
instead, because only bash
uses .bash_profile
and .bash_login
. But in .profile
, you should not have an unguarded . "$HOME/.bashrc"
, because other shells than bash
--and most desktop environments--also run commands from .profile
.
You should exercise similar care if you decide to make /etc/profile
source /etc/bash.bashrc
. And in all cases when you use the .
or source
builtin to source one startup script from another (.
and source
are interchangeable in bash
), make sure you're not creating an infinite loop where one file sources another, which sources the original file.
What you should do...
...is something I cannot know for sure based on the information you've given, because I don't know which of the files I mentioned above you actually have and what they contain.
I believe the description I've given should be sufficient to enable you to figure out what changes to make, but you might not actually be sure which commands from /etc/bash.bashrc
or .bashrc
you want run in both login and non-login shells, and which ones you want to keep just for non-login shells. (Or perhaps some of them--like setting environment variables such as PATH
--you will want to run only for login shells.)
So if, for that or any other reason, you want a more detailed answer, then I recommend you edit your question to provide that information: the name, as well as the complete and exact text, of each of those files that you have. (Other users looking for help with this should of course not edit this question, but should post new questions if the solution is not first found by searching.)
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
I noticed when I run /usr/bin/bash, colors come back. (However, I don't have my profile settings such as aliases and paths).
Apparently the commands that set those things up are only run for non-login shells.
Interactive login shells use different startup scripts from other interactive shells.
The commands that set up colored output are probably in the .bashrc
file in your home directory, or in the systemwide /etc/bash.bashrc
. Commands from those files are run for interactive shells that are not login shells, but they are not run from interactive login shells unless a command in a different startup script sources .bashrc
. You should check those files.
When bash
starts as a login shell, it runs commands from /etc/profile
as well as the first of .bash_profile
, .bash_login
, and .profile
that exists in your home directory. Run man bash
for details.
Commands in "profile" files run even in noninteractive login shells for which you likely don't want to set up colorization, and where doing so might even produce errors. In particular, most desktop environments run commands from your .profile
file. So if you add commands for colorization into a "profile" file, you should consider making it run only in interactive shells. Furthermore, some of your commands should only be run in bash
but not in other shells, and you should make sure that is still the case (see below).
One way to determine if a shell is interactive is to check if the PS1
prompt variable exists and is nonempty. You can put this command after all the commands in a "profile" file that you want run even for noninteractive login shells, but before any commands you want run in interactive shells:
[ -z "$PS1" ] && return
Sometimes the interactivity check could be in the "rc" file.
In some operating systems, including Debian and Ubuntu, the default .profile
(copied from /etc/skel/
when a user account is created) sources--that is, runs all commands from--.bashrc
. Similarly, /etc/profile
sources /etc/bash.bashrc
. Not all operating systems where bash
is the default shell do this, though. Probably your system does not.
In those systems, the default .bashrc
and /etc/bash.bashrc
have a line like that at the top before any other commands. Specifically, /etc/bash.bashrc
has that line exactly, while .bashrc
checks if the shell is interactive in a different way:
case $- in
*i*) ;;
*) return;;
esac
This works because an interactive bash
shell has an i
in the special parameter $-
. I mention it mainly in case you prefer to check in that way.
Sometimes it can make sense to conditionally source an "rc" from a "profile."
Depending on your situation, you might want--for example--to make whichever of the "profile" files in your home directory is being used source .bashrc
, as Debian does. I cannot advise you to do this because it depends on what you actually have in all those files. But the way Debian and Ubuntu do it is like this:
# if running bash
if [ -n "$BASH_VERSION" ]; then
# include .bashrc if it exists
if [ -f "$HOME/.bashrc" ]; then
. "$HOME/.bashrc"
fi
fi
Commands in .bashrc
are usually only capable of being run by bash
, so you should not set things up so other shells will run them inadvertently. That' what the code above achieves. In .bash_profile
or .bash_login
, you can have just . "$HOME/.bashrc"
instead, because only bash
uses .bash_profile
and .bash_login
. But in .profile
, you should not have an unguarded . "$HOME/.bashrc"
, because other shells than bash
--and most desktop environments--also run commands from .profile
.
You should exercise similar care if you decide to make /etc/profile
source /etc/bash.bashrc
. And in all cases when you use the .
or source
builtin to source one startup script from another (.
and source
are interchangeable in bash
), make sure you're not creating an infinite loop where one file sources another, which sources the original file.
What you should do...
...is something I cannot know for sure based on the information you've given, because I don't know which of the files I mentioned above you actually have and what they contain.
I believe the description I've given should be sufficient to enable you to figure out what changes to make, but you might not actually be sure which commands from /etc/bash.bashrc
or .bashrc
you want run in both login and non-login shells, and which ones you want to keep just for non-login shells. (Or perhaps some of them--like setting environment variables such as PATH
--you will want to run only for login shells.)
So if, for that or any other reason, you want a more detailed answer, then I recommend you edit your question to provide that information: the name, as well as the complete and exact text, of each of those files that you have. (Other users looking for help with this should of course not edit this question, but should post new questions if the solution is not first found by searching.)
add a comment |Â
up vote
1
down vote
I noticed when I run /usr/bin/bash, colors come back. (However, I don't have my profile settings such as aliases and paths).
Apparently the commands that set those things up are only run for non-login shells.
Interactive login shells use different startup scripts from other interactive shells.
The commands that set up colored output are probably in the .bashrc
file in your home directory, or in the systemwide /etc/bash.bashrc
. Commands from those files are run for interactive shells that are not login shells, but they are not run from interactive login shells unless a command in a different startup script sources .bashrc
. You should check those files.
When bash
starts as a login shell, it runs commands from /etc/profile
as well as the first of .bash_profile
, .bash_login
, and .profile
that exists in your home directory. Run man bash
for details.
Commands in "profile" files run even in noninteractive login shells for which you likely don't want to set up colorization, and where doing so might even produce errors. In particular, most desktop environments run commands from your .profile
file. So if you add commands for colorization into a "profile" file, you should consider making it run only in interactive shells. Furthermore, some of your commands should only be run in bash
but not in other shells, and you should make sure that is still the case (see below).
One way to determine if a shell is interactive is to check if the PS1
prompt variable exists and is nonempty. You can put this command after all the commands in a "profile" file that you want run even for noninteractive login shells, but before any commands you want run in interactive shells:
[ -z "$PS1" ] && return
Sometimes the interactivity check could be in the "rc" file.
In some operating systems, including Debian and Ubuntu, the default .profile
(copied from /etc/skel/
when a user account is created) sources--that is, runs all commands from--.bashrc
. Similarly, /etc/profile
sources /etc/bash.bashrc
. Not all operating systems where bash
is the default shell do this, though. Probably your system does not.
In those systems, the default .bashrc
and /etc/bash.bashrc
have a line like that at the top before any other commands. Specifically, /etc/bash.bashrc
has that line exactly, while .bashrc
checks if the shell is interactive in a different way:
case $- in
*i*) ;;
*) return;;
esac
This works because an interactive bash
shell has an i
in the special parameter $-
. I mention it mainly in case you prefer to check in that way.
Sometimes it can make sense to conditionally source an "rc" from a "profile."
Depending on your situation, you might want--for example--to make whichever of the "profile" files in your home directory is being used source .bashrc
, as Debian does. I cannot advise you to do this because it depends on what you actually have in all those files. But the way Debian and Ubuntu do it is like this:
# if running bash
if [ -n "$BASH_VERSION" ]; then
# include .bashrc if it exists
if [ -f "$HOME/.bashrc" ]; then
. "$HOME/.bashrc"
fi
fi
Commands in .bashrc
are usually only capable of being run by bash
, so you should not set things up so other shells will run them inadvertently. That' what the code above achieves. In .bash_profile
or .bash_login
, you can have just . "$HOME/.bashrc"
instead, because only bash
uses .bash_profile
and .bash_login
. But in .profile
, you should not have an unguarded . "$HOME/.bashrc"
, because other shells than bash
--and most desktop environments--also run commands from .profile
.
You should exercise similar care if you decide to make /etc/profile
source /etc/bash.bashrc
. And in all cases when you use the .
or source
builtin to source one startup script from another (.
and source
are interchangeable in bash
), make sure you're not creating an infinite loop where one file sources another, which sources the original file.
What you should do...
...is something I cannot know for sure based on the information you've given, because I don't know which of the files I mentioned above you actually have and what they contain.
I believe the description I've given should be sufficient to enable you to figure out what changes to make, but you might not actually be sure which commands from /etc/bash.bashrc
or .bashrc
you want run in both login and non-login shells, and which ones you want to keep just for non-login shells. (Or perhaps some of them--like setting environment variables such as PATH
--you will want to run only for login shells.)
So if, for that or any other reason, you want a more detailed answer, then I recommend you edit your question to provide that information: the name, as well as the complete and exact text, of each of those files that you have. (Other users looking for help with this should of course not edit this question, but should post new questions if the solution is not first found by searching.)
add a comment |Â
up vote
1
down vote
up vote
1
down vote
I noticed when I run /usr/bin/bash, colors come back. (However, I don't have my profile settings such as aliases and paths).
Apparently the commands that set those things up are only run for non-login shells.
Interactive login shells use different startup scripts from other interactive shells.
The commands that set up colored output are probably in the .bashrc
file in your home directory, or in the systemwide /etc/bash.bashrc
. Commands from those files are run for interactive shells that are not login shells, but they are not run from interactive login shells unless a command in a different startup script sources .bashrc
. You should check those files.
When bash
starts as a login shell, it runs commands from /etc/profile
as well as the first of .bash_profile
, .bash_login
, and .profile
that exists in your home directory. Run man bash
for details.
Commands in "profile" files run even in noninteractive login shells for which you likely don't want to set up colorization, and where doing so might even produce errors. In particular, most desktop environments run commands from your .profile
file. So if you add commands for colorization into a "profile" file, you should consider making it run only in interactive shells. Furthermore, some of your commands should only be run in bash
but not in other shells, and you should make sure that is still the case (see below).
One way to determine if a shell is interactive is to check if the PS1
prompt variable exists and is nonempty. You can put this command after all the commands in a "profile" file that you want run even for noninteractive login shells, but before any commands you want run in interactive shells:
[ -z "$PS1" ] && return
Sometimes the interactivity check could be in the "rc" file.
In some operating systems, including Debian and Ubuntu, the default .profile
(copied from /etc/skel/
when a user account is created) sources--that is, runs all commands from--.bashrc
. Similarly, /etc/profile
sources /etc/bash.bashrc
. Not all operating systems where bash
is the default shell do this, though. Probably your system does not.
In those systems, the default .bashrc
and /etc/bash.bashrc
have a line like that at the top before any other commands. Specifically, /etc/bash.bashrc
has that line exactly, while .bashrc
checks if the shell is interactive in a different way:
case $- in
*i*) ;;
*) return;;
esac
This works because an interactive bash
shell has an i
in the special parameter $-
. I mention it mainly in case you prefer to check in that way.
Sometimes it can make sense to conditionally source an "rc" from a "profile."
Depending on your situation, you might want--for example--to make whichever of the "profile" files in your home directory is being used source .bashrc
, as Debian does. I cannot advise you to do this because it depends on what you actually have in all those files. But the way Debian and Ubuntu do it is like this:
# if running bash
if [ -n "$BASH_VERSION" ]; then
# include .bashrc if it exists
if [ -f "$HOME/.bashrc" ]; then
. "$HOME/.bashrc"
fi
fi
Commands in .bashrc
are usually only capable of being run by bash
, so you should not set things up so other shells will run them inadvertently. That' what the code above achieves. In .bash_profile
or .bash_login
, you can have just . "$HOME/.bashrc"
instead, because only bash
uses .bash_profile
and .bash_login
. But in .profile
, you should not have an unguarded . "$HOME/.bashrc"
, because other shells than bash
--and most desktop environments--also run commands from .profile
.
You should exercise similar care if you decide to make /etc/profile
source /etc/bash.bashrc
. And in all cases when you use the .
or source
builtin to source one startup script from another (.
and source
are interchangeable in bash
), make sure you're not creating an infinite loop where one file sources another, which sources the original file.
What you should do...
...is something I cannot know for sure based on the information you've given, because I don't know which of the files I mentioned above you actually have and what they contain.
I believe the description I've given should be sufficient to enable you to figure out what changes to make, but you might not actually be sure which commands from /etc/bash.bashrc
or .bashrc
you want run in both login and non-login shells, and which ones you want to keep just for non-login shells. (Or perhaps some of them--like setting environment variables such as PATH
--you will want to run only for login shells.)
So if, for that or any other reason, you want a more detailed answer, then I recommend you edit your question to provide that information: the name, as well as the complete and exact text, of each of those files that you have. (Other users looking for help with this should of course not edit this question, but should post new questions if the solution is not first found by searching.)
I noticed when I run /usr/bin/bash, colors come back. (However, I don't have my profile settings such as aliases and paths).
Apparently the commands that set those things up are only run for non-login shells.
Interactive login shells use different startup scripts from other interactive shells.
The commands that set up colored output are probably in the .bashrc
file in your home directory, or in the systemwide /etc/bash.bashrc
. Commands from those files are run for interactive shells that are not login shells, but they are not run from interactive login shells unless a command in a different startup script sources .bashrc
. You should check those files.
When bash
starts as a login shell, it runs commands from /etc/profile
as well as the first of .bash_profile
, .bash_login
, and .profile
that exists in your home directory. Run man bash
for details.
Commands in "profile" files run even in noninteractive login shells for which you likely don't want to set up colorization, and where doing so might even produce errors. In particular, most desktop environments run commands from your .profile
file. So if you add commands for colorization into a "profile" file, you should consider making it run only in interactive shells. Furthermore, some of your commands should only be run in bash
but not in other shells, and you should make sure that is still the case (see below).
One way to determine if a shell is interactive is to check if the PS1
prompt variable exists and is nonempty. You can put this command after all the commands in a "profile" file that you want run even for noninteractive login shells, but before any commands you want run in interactive shells:
[ -z "$PS1" ] && return
Sometimes the interactivity check could be in the "rc" file.
In some operating systems, including Debian and Ubuntu, the default .profile
(copied from /etc/skel/
when a user account is created) sources--that is, runs all commands from--.bashrc
. Similarly, /etc/profile
sources /etc/bash.bashrc
. Not all operating systems where bash
is the default shell do this, though. Probably your system does not.
In those systems, the default .bashrc
and /etc/bash.bashrc
have a line like that at the top before any other commands. Specifically, /etc/bash.bashrc
has that line exactly, while .bashrc
checks if the shell is interactive in a different way:
case $- in
*i*) ;;
*) return;;
esac
This works because an interactive bash
shell has an i
in the special parameter $-
. I mention it mainly in case you prefer to check in that way.
Sometimes it can make sense to conditionally source an "rc" from a "profile."
Depending on your situation, you might want--for example--to make whichever of the "profile" files in your home directory is being used source .bashrc
, as Debian does. I cannot advise you to do this because it depends on what you actually have in all those files. But the way Debian and Ubuntu do it is like this:
# if running bash
if [ -n "$BASH_VERSION" ]; then
# include .bashrc if it exists
if [ -f "$HOME/.bashrc" ]; then
. "$HOME/.bashrc"
fi
fi
Commands in .bashrc
are usually only capable of being run by bash
, so you should not set things up so other shells will run them inadvertently. That' what the code above achieves. In .bash_profile
or .bash_login
, you can have just . "$HOME/.bashrc"
instead, because only bash
uses .bash_profile
and .bash_login
. But in .profile
, you should not have an unguarded . "$HOME/.bashrc"
, because other shells than bash
--and most desktop environments--also run commands from .profile
.
You should exercise similar care if you decide to make /etc/profile
source /etc/bash.bashrc
. And in all cases when you use the .
or source
builtin to source one startup script from another (.
and source
are interchangeable in bash
), make sure you're not creating an infinite loop where one file sources another, which sources the original file.
What you should do...
...is something I cannot know for sure based on the information you've given, because I don't know which of the files I mentioned above you actually have and what they contain.
I believe the description I've given should be sufficient to enable you to figure out what changes to make, but you might not actually be sure which commands from /etc/bash.bashrc
or .bashrc
you want run in both login and non-login shells, and which ones you want to keep just for non-login shells. (Or perhaps some of them--like setting environment variables such as PATH
--you will want to run only for login shells.)
So if, for that or any other reason, you want a more detailed answer, then I recommend you edit your question to provide that information: the name, as well as the complete and exact text, of each of those files that you have. (Other users looking for help with this should of course not edit this question, but should post new questions if the solution is not first found by searching.)
answered Oct 16 '17 at 4:26
Eliah Kagan
3,16221530
3,16221530
add a comment |Â
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%2f398076%2fno-colored-output-with-login-option-in-bash%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
Most likely related to the
TERM
environment variable.â Satà  Katsura
Oct 14 '17 at 8:08
1
=xterm in both cases
â zhekaus
Oct 14 '17 at 8:14