-   Programming (
-   -   ssh : remote command execution doesn't work for modifying env variables (

pypieuvre 02-14-2006 09:58 AM

ssh : remote command execution doesn't work for modifying env variables
I m trying to open an ssh connection on a server and immediatly execute a command after bash login.
I set up the rsa authentication to avoid interactive passwords issues.

I'd like to customize the prompt of the shell on the server, WITHOUT modifying anything on it (specially .bashrc or .bash_profile)

I tried

$> ssh mylogin@myhost "export PS1=\"my prompt\";bash --login"
It works as long as no personal customization is done on targeted account .bashrc : in that case the variable is overwritten ....


$> ssh mylogin@myhost "bash --login; export PS1=\"my prompt\""
doesn't work at all.


$> export PS1='my prompt' | ssh mylogin@myhost
doesnt give me any prompt at all


$> ssh -t ssh mylogin@myhost <<EOF export PS1=my prompt


Don't know what to do ... do you have any idea ?
PS: Sorry for my english ...

chrism01 02-14-2006 05:00 PM

What I'd do is create a shell file with your temp alterations and source it befoe executing any other cmds:

ssh mylogin@myhost

That's a dot followed by a space followed by shell_file name

pypieuvre 02-15-2006 04:57 AM

The problem is that I want to do it automatically and without modifying the server's configuration (no script on the server) ...

german 02-15-2006 11:29 AM

try this:


ssh mylogin@myhost "export PS1=\"my prompt\";bash --login --norc"
from the bash man page:


--norc Do  not  read  and  execute  the system wide initialization file
              /etc/bash.bashrc and the personal initialization file  ~/.bashrc
              if  the  shell  is interactive.  This option is on by default if
              the shell is invoked as sh.

Matir 02-15-2006 12:36 PM

Yes... bash --login (without --norc) will always read in configuration files. Specifying the export afterward will set the environment variable when bash EXITS.

chrism01 02-15-2006 04:54 PM

Well, my suggestion would only temporarily alter the env for that run of that ssh call; ie when the process exits, the env goes away and in any case no other process will be affected unless they source the script also.
Normal programming practice.

pypieuvre 02-16-2006 02:57 AM

Good points, thanks for the attention guys ;-)

Crism01 I agree with you regarding the way to think about the problem, It's exactly what I'm trying to do, but again your script has to be stored on the server side (no ?), what I'd like to avoid ... and to be run automatically after bash launch.

German , It could be a solution but I don't want to prevent the environmnent to be customized except for specific variables. With your solution the account aliases and variables will be skiped ...

pypieuvre 02-22-2006 03:24 AM

No more ideas ?

chrism01 02-23-2006 10:23 PM

I think we need more info on eactly WHAT you are trying to do and WHY....
After all, if you are allowed to login and run stuff on the remote box, you are allowed to add scripts to it... or maybe just manually type in any changes you want???

pypieuvre 02-24-2006 09:35 AM

You're right it could be a solution to deploy some configuration files or scripts on the remote box, the problem is that I ve got about 9 000 of them ...

What I m doing is building a centralized gateway, mandatory to access these thousands of servers (to control and grant accesses). You connect to the central gateway, choose the host you want to connect and then your connection is forwarded to the remote server (exactly like you would do directly).

BUT after opening the connection between the gateway and the remote box I would like to modify an environmnent variable 'on the fly' for the bash session...

Am I a little more clear ? I recognize the issue is a bit particular and difficult to realise.

german 02-24-2006 09:50 AM

what about a grep of the .bashrc and /etc/bashrc files before running bash? something like (totally untested and my regexp knowledge sucks):


ssh login@myhost "grep [^PS1] ~/.bashrc | sh; bash --login --norc"
edit: on second thought this absolutely wouldn't work because it uses 2 separate instances of bash.

All times are GMT -5. The time now is 11:28 PM.