When I connect over ssh to remote hosts everything is just a single font/color. I would like to have colours like I do locally e.g. green for executable and blue for symlinks etc. And such that when I run $ git diff on the ssh host it shows me diff with colours =)
This worked for me:
ssh -t my_host my_command
-t was the key. Explained:
-t Force pseudo-tty allocation. This can be used to execute arbitrary screen-based programs on a remote machine, which can be very useful, e.g. when implementing menu services. Multiple -t options force tty allocation, even if ssh has no local tty.
Since the colors worked fine while being loggged in directly, I just un-uncommented the line
force_color_prompt=yes in the file
~/.bashrc, that gave me colors over ssh, too:
# uncomment for a colored prompt, if the terminal has the capability; turned # off by default to not distract the user: the focus in a terminal window # should be on the output of commands, not on the prompt force_color_prompt=yes
(Ubuntu 18.04 LTS)
I tried changing
~./bashrc settings (both on local and remote server), but it did not seem to work.
Then I noticed that
~/.bashrc of remote server does not even get executed if I connect to it over ssh. So I made
~/.bashrc of remote server to execute by puttinng
if [ -f ~/.bashrc ]; then . ~/.bashrc fi in remote server's
~/.bash_profile. (based on https://stackoverflow.com/questions/820517/bashrc-at-ssh-login).
So this solution did not require changing any
~/bashrc files directly but it did require changing
~/bash_profile file of remote server so that
~/bashrc file of remote server got executed.
In my situation, I recently installed
chef-local and it asked me to add a line to
.bash_profile. When I sign in,
.bashrc never loads anymore, because it saw
What I did was to add a line in
source .bashrc export PATH="/opt/chefdk/embedded/bin:$PATH"
I logged out and back in and got my colored terminal right away.
There is a comment from "Mike E" above that contained the answer for me, but it is not only hard to read, it is kind of hard to figure out what he means if you don't use
.bashrc a lot - and I don't.
After screwing around a bit, I got the desired results by changing the following lines in
~/.bashrc on the machine I was logging into with ssh:
# set a fancy prompt (non-color, unless we know we "want" color) case "$TERM" in xterm-color|*-256color) color_prompt=yes;; esac
# set a fancy prompt (non-color, unless we know we "want" color) case "$TERM" in xterm-color|*-256color) color_prompt=yes;; xterm) color_prompt=yes;; esac
I am thinking I could have just added "|xterm" after "color" in the first line, or dug around and figure out why ssh was using "xterm" instead of "xterm-color" and change that, but this works and I have other things to do now.
cd cat << 'EOF' >color_terminals_over_ssh.sh #!/bin/bash #Must pass either enable or disable to script #./color_terminals_over_ssh.sh enable DO=$1 if [[ $DO = "enable" ]] then sudo sed -i '/force_color_prompt=yes/s/^#//g' /home/*/.bashrc sudo sed -i '/force_color_prompt=yes/s/^#//g' /root/.bashrc sudo su elif [[ $DO = "disable" ]] then sudo sed -i '/force_color_prompt=yes/s/^/#/g' /home/*/.bashrc sudo sed -i '/force_color_prompt=yes/s/^/#/g' /root/.bashrc sudo su fi cat ~/.bashrc | grep force_color_prompt=yes EOF chmod +x color_terminals_over_ssh.sh ./color_terminals_over_ssh.sh enable
I had this issue after creating a new user on Linux (Ubuntu). Setting
force_color_prompt=yes didn't do it for me.
I forgot to specify the shell, so it went for the default
/bin/sh, redirecting to
/bin/dash apparently on my distribution. When manually setting it to
/bin/bash everything worked out of the box.
So in my case I could have used the
-s flag when adding the user (so
useradd -s /bin/bash ... to specify the shell. Instead I used
chsh -s /bin/bash to set it after creation.