Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I use a specific PS1 prompt that I like. I share a few logins with other other people on a few different servers. I was wondering if there was a way to specify in my local bash profile a remote prompt or any other way other then copy and pasting each time I remote in.

share|improve this question
add comment

8 Answers

up vote 8 down vote accepted

Upload a file on each remote machine, say ~/.my_custom_bashrc, with your custom bash configuration, (in this case PS1=...) then launch ssh with:

ssh user@host -t "bash --rcfile ~/.my_custom_bashrc -i"

You can easily use a bash function as wrapper for readability.

share|improve this answer
add comment

If you just want to send the PS1 variable, and it doesn't contain a ' (single quote), try:

ssh targethost -t "PS1='$PS1'; exec bash"

The local .bashrc may well overwrite PS1 though (thanks to Dennis Williamson for pointing this out).

There are ways to transmit environment variables over ssh, but they're typically disabled in the server configuration. If the PermitUserEnvironment directive is enabled in the server configuration and each user has their own key pair (yeah, you might not be so lucky), you can add environment="PS1=…" to the line in ~/.ssh/authorized_keys corresponding to your key.

If you'd like to keep your own configuration on a shared user account, you can create your own configuration file directory and set the HOME environment variable to point to that directory.

ssh targethost mkdir mrstatic.home
scp .bashrc targethost:mrstatic.home/

Create symbolic links in the mrstatic.home directory pointing back to the corresponding entry in the parent directory when you want to share a file with the other users.

Then, log in with

ssh targethost -t 'HOME=~/mrstatic.home; exec bash'`

If you're willing to modify the remote .profile (or other initialisation file), you can probably automate your settings. Many sites allow LC_* environment variables through (normally they are used for locale settings). If both these conditions are met, you can set a variable that isn't actually used for locales, say LC_USER, on the client side, and test it in the server .profile.

(Of course shared accounts are a bad idea, but I realize you may not be in a position to change that situation.)

share|improve this answer
add comment

you can specify environment variables on the client side and if the ssh-server allows it (check man sshd-config), these variables are copied to the session when you log into the machine.

so, you would have to configure the .bashrc on the server to check an existing PS1 (or whatever variable) and only set PS1 if it is not set already.

or, which make things simpler, you bundle your settings into a function .. and deploy that function either as a special file your source on demand (source joes_bashrc) or directly to the .bashrc. having your own file seems a bit more robust. the other folks might use your settings but are not forced to do so.

share|improve this answer
add comment
ssh -t user@host "remote=$PS1 bash -i"

Then, at the prompt:

PS1=$remote
share|improve this answer
    
A sophisticated bash prompt is likely to break if it's not quoted (coming from you, I'm surprised). And why the extra command, and not just "PS1='$PS1' bash -i" (and why not exec, too)? –  Gilles Dec 11 '10 at 23:35
    
@Gilles: Missing quoting: sloppiness. Extra command: it wouldn't be unusual for PS1 to be overwritten during shell startup. No exec: during testing on my system it didn't seem to make any difference - no extra process. –  Dennis Williamson Dec 12 '10 at 2:19
    
Oh, yes, that's a good point, the local .bashrc is likely to overwrite PS1. –  Gilles Dec 12 '10 at 14:11
add comment

Put your PS1 prompt in ~/.ssh/environment and ssh session will carry it to every host you login. It works for me with openssh 4.3p2 .

share|improve this answer
    
This only works if the server's configuration has enabled PermitUserEnvironment, which is off by default. –  Flimm Jul 3 '13 at 16:44
add comment

If you wanna do it without needing an extra scp you can do something like this:

ssh -t srvname ' cp ~/.bashrc ~/.bashrc.n &>/dev/null ; echo "LS_COLORS=\"no=00:fi=00:ETC:ETC:ETC\";" >> ~/.bashrc.n ; echo "export LS_COLORS" >> ~/.bashrc.n ; echo "alias ls=\"ls --color=auto\";" >> ~/.bashrc.n ; exec bash --rcfile ~/.bashrc.n'

That'll generate a .bashrc.n that's based on the servers bashrc but with your overrides.

share|improve this answer
    
This is why some people are afraid of terminals. –  Herman Torjussen Nov 11 '12 at 20:57
add comment

Do not share logins. SSH as yourself, then do sudo -su shareduser (-s means "shell").

Make sudo keep your home directory:

Defaults env_keep += "HOME"
share|improve this answer
    
When I get promoted I will try and enact that policy but for now I am stuck with this. –  MrStatic Dec 11 '10 at 20:30
add comment

You could do stuff like mounting your home over sshfs/nfs, but the easiest solution is to scp your bashrc across to the new machine. This also brings aliases and stuff.

share|improve this answer
    
As I stated in my question I share these logins with other people. I am quite sure they would not appreciate me writing over the base profile. –  MrStatic Dec 11 '10 at 19:19
1  
Mounting $HOME over NFS is insane. Just sayin'. –  Wesley Rice Dec 11 '10 at 20:35
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.