I want to use the PS1 setting in my .bashrc file to change the color of the terminal based on whether I'm on my local machine or using ssh.
My current .bashrc file on both my local machine and the ssh server is (the default):
PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u#\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '
I've tried adding "\e[40m" to the end, but only changes part of the background of the terminal, leaving a black bar in the middle
How would I go about changing the PS1 setting to, say, my local terminal is dark blue and the ssh terminal is dark gray?
Thanks!
Just out of curiosity, doesn't that remote machine set its own PS1 value which means however you set your prompt locally, that remote machine will override it?
One way around this is to setup a function to replace your actual ssh command. Have that function set the color of your terminal, and then run the actual ssh command:
function ssh_function
{
printf "\e[40m\e[37m" # Grey on black
clear
\ssh $# || read # Actual ssh command
printf "\e[0m" # Reset terminal
clear
}
Now, create an alias:
alias ssh="ssh_function"
Now, when you run ssh, it will run your ssh_function which sets the screen color before executing ssh and then resets your screen colors once out of ssh. The clear is to clear your terminal, so you get a constant color. Otherwise, it merely resets the color at your prompt.
And then hope that the remote PS1 environment variable doesn't reset the terminal color on you.
Related
I have a PS1 varible in bash_profile file as
orange=$(tput setaf 166);
yellow=$(tput setaf 228);
green=$(tput setaf 71);
white=$(tput setaf 15);
bold=$(tput bold);
reset=$(tput sgr0);
PS1="\[${bold}\]";
PS1+="\[${orange}\]\u"; # username
PS1+="\[${white}\]#";
PS1+="\[${yellow}\]\h "; # host
PS1+="\[${green}\]\w"; # working directory
PS1+="\[${white}\]\$ \[${reset}\]"; # '$' (and reset color)
export PS1;
When I open the new terminal instance it's showing everything properly except color.
But, when I execute the command
source .bash_profile
the color is working. It disappears if I open a new tab.
But, In a new terminal instance, without executing the source command,
the color works for
export PS1="\[\033[35m\]\t\[\033[m\]-\[\033[36m\]\u\[\033[m\]#\[\033[32m\]\h:\[\033[33;1m\]\w\[\033[m\]\$ "
[
What's the reason for this weird behavior?
In breif, in a new terminal session,
first PS1 is not displaying colors but the second ps1 put in the same bash_profile file is displying it.
But the first one is displaying colors when it is sourced.
Note: I am using mac.
I m also sure that the variable is getting set in bash_profile
but the color is not being set.
You should investigate a little more (yes even more).
In each case you should use printf "%q\n" "$PS1" to see the exact value of the variable PS1 (with escaped unprintable characters). Are you just trying to add the colors to an already set PS1 variable? So, if you get the uncolored output, could that be because your code just wasn't executed so the original value is still set? Then just the PROFILE script isn't executed.
.bash_profile typically only is executed when a login-shell is started. Nowadays many distributions don't get it right and are full of workarounds in this matter, so they often contain .bashrc files which source .bash_profile in their beginning. .bashrc is sourced for each new shell, so effectively, your .bash_profile might well be sourced for each shell as well.
I could guess that your .bashrc first sources .bash_profile and then sets the PS1 to a value like yours, just without the colors. But of course, that's guesswork.
I suspect in the OP's case that using ~/.bashrc rather than ~/.bash_profile to set the colours, is all that is required.
Here is how things work:
There are a number of files involved in setting up your bash environment.
/etc/profile sets the system-wide profile
~/.bash_profile, ~/.bash_login, ~/.profile - These are read by default when bash is invoked as a login shell
~/.bashrc - This is always read unless bash is invoked as sh or bash is invoked as bash --norc
~/.bash_logout - login shell cleanup
~/.inputrc - readline initialisation file.
Which files, and order that these files are read depends on exactly how bash is invoked.
There are a number of cases not all of which are mutually exclusive:
login shell
interactive shell
non-interactive shell
posix mode
bash invoked with stdin connected to network connection (yes
it will know)
bash invoked as sh
bash is invoked with the effective uid/gid not equal to the real uid/gid
You need to be aware of which cases apply to your invocation in order to determine which files will be read.
man bash and search for invocation, for the exact details.
I had installed solarized color scheme/theme for my xterm-256 terminal. It was the one causing the issue. When I change the color scheme, the PS1 is working perfectly.
I have a lock screen script (via i3lock) that runs correctly in a terminal window, but not when used as a keybind in i3 config.
The script is pretty straightforward:
# Take screenshot
scrot /tmp/screenshot.png
# Pixelate and add central logo
magick /tmp/screenshot.png -scale 10% -scale 1000% -gravity center /home/user/bin/archlogo.png -composite /tmp/lock.png
# Lock using pixelated image & logo
i3lock -e -f -c 000000 -i /tmp/lock.png
The script is saved to ~/bin/lock and executable. The directory has also been identified in my ~/.bash_profile.
There is no error message, only brief flash of the terminal cursor.
The relevant lines in ~/.config/i3/config:
# lock screen
bindsym $mod+l exec lock
(the default keybind for $mod+l was deleted and i3 was restarted).
~/.bash_profile is a configuration file for bash and as such is only loaded when bash starts (as an interactive login shell or when it is expclicitly sourced by other bash configuration files, e.g. ~/.bashrc). i3 itself does not load anything from ~/.bash_profile and neither does X.org. So unless you start your X session from a bash shell (for example with startx from the console) any changes to PATH will not have been loaded and i3 will not know about ~/bin being added to PATH.
If you want to modify PATH for i3 itself, then ~/.bash_profile is not the right place. Unfortunately for X sessions the "right place" very much depends on how you start it (e.g. from the console with start or with some desktop manager like lightdm or kdm).
You could add a setting for PATH to ~/.pam_environment, which - at least on Arch - should prepend the given value to the system default setting of PATH. For example, if you put the follwing in your ~/.pam_environment
PATH=/home/soundscape/bin
and the default value is
/usr/local/sbin:/usr/local/bin:/usr/bin
you will end up with
/home/soundscape/bin:/usr/local/sbin:/usr/local/bin:/usr/bin
Of course, this value might be further modified by any settings in ~/.bash_profile or similar files when you start bash.
Note: ~/.pam_environment does not support any parameter expansion, so adding something like
PATH=${PATH}:${HOME}/bin
will not work.
I remember something similar... try specifying the absolute path like this, might be that exec doesn't honor the $PATH environment variable:
# lock screen
bindsym $mod+l exec "${HOME}/bin/lock"
Long time Mac (read GUI) user who recently started running Ubuntu and has spent a week or so customizing my .bashrc (Ubuntu) file and .bash_profile (Mac) for informative and colorful PS1 and terminal output.
I've got this tiny little function:
function colors2nums()
{ for code in {0..255}; do echo -e "\e[38;05;${code}m $code: Test"; done }
that displays 256 colors with codes so I can choose the one I want...
It works perfectly in Ubuntu (14.0.4 LTS, Gnome terminal) and does not work at all on the Mac (OS 10.7.5 both iTerm & Terminal.app).
The PROMPT_COMMAND function of the .bashrc file on Ubuntu is exactly the same, copied & pasted line-for-line as the Mac's PROMPT_COMMAND function is in .bash_profile.
Both PS1 prompts are identical in color (with just some odd spacing on the Mac side) and ls -GFa (or any variant) prints in the colors set by LS_COLORS and .dircolors. So colors are working for some output, but not all. On the Mac, I get 256 lines in the same color as my terminal input set by the last escaped color (green, white, whatever) in my PS1.
WTH?!?
And yes, I've tried 2 variations of the trap - DEBUG (hack?):
#trap 'echo -ne \e[0m' DEBUG
trap 'printf "\e[0m" "$_"' DEBUG
that works to reset the output on the Ubuntu side of things. Neither works on the Mac.
What am I missing?
Having more than just a few colors in a terminal is a relatively recent "invention", and not all terminal programs are able to handle it.
Also note that it's the actual terminal program that handles it, the shell has nothing to do with it.
Try using printf instead:
for code in {0..255}; do printf "\e[38;05;${code}m $code: Test"; done
I'm trying to change the foreground color of the terminal when I log in into a server with an ssh client.
With putty I can achieve this very simply, setting the foreground color in the color section of the client, but I'd like to set this at server side, e.g. in the bashrc or the bash_profile files.
I've tried tput and setterm and they works fine, but after a ls command the color is resetted.
tput setaf 1
setterm -term linux -back red -fore white -clear rest
Any solution? Thanks everybody
You can't do this at the server level. You can set the current foreground color (what those commands are doing) at the shell/etc. level but when the shell/other programs tell the terminal to reset it will fall back to its default color which is going to be 0.
To change what color is displayed when programs ask for color 0 you need to change that at the terminal level (like the putty settings).
One workaround I've find is to add the following lines in the bottom of the ~/.bash_profile :
export PROMPT_COMMAND="$PROMPT_COMMAND;tput setaf 1"
This will execute the command to set the color (tput setaf 1) after every terminal command (and before the next prompt)
Reference: http://www.tldp.org/HOWTO/Bash-Prompt-HOWTO/x264.html
When invoke vi in a session inside SCREEN, I always encounter error:
bash-3.2$ vi perf332.db2
ex: 0602-108 screen is not a recognized terminal type.
[Press return to continue]
[Using open mode]
After I explicitly export TERM=xterm or something, it works fine.
My SCREEN is running on a Linux server, and I SSH from there to a AIX server.
The default TERM variable for screen is TERM=screen. This is what its supposed to be.
You might consider putting something like this in your .bashrc to change the TERM variable to xterm when its screen.
if [[ $TERM = screen ]]; then
export TERM=xterm
fi
However I do not recommend doing this as this might confuse other application.
It seems vi does not know how to send commands to screen when the TERM variable is set to screen. The other way of getting around this would be to install vim which does understand how to communicate with screen.
Try putting shell -$SHELL into your ~/.screenrc file