mjhjmtu

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?

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.)