Initialization script and ssh

Hi,

where can I define which initialization scripts are read
when using ssh?

My problem is that when I login via ssh on a machine, I can
run "xterm" without any problems. Also

ssh HOSTNAME /usr/X11R6/bin/xterm

works fine. However, when I skip the absolute path and invoke

set HOSTNAME xterm

I get the error message:
bash: line 1: xterm: command not found

Any ideas?

Regards,
Chris

Christian Christmann wrote:
> Hi,
>
> where can I define which initialization scripts are read
> when using ssh?
>
> My problem is that when I login via ssh on a machine, I can
> run "xterm" without any problems. Also
>
> ssh HOSTNAME /usr/X11R6/bin/xterm
>
> works fine. However, when I skip the absolute path and invoke
>
> set HOSTNAME xterm
>
> I get the error message:
> bash: line 1: xterm: command not found

/usr/X11R6/bin is not in the seach path set by the daemon. Try the command:
$ ssh HOSTNAME "/usr/bin/echo \$PATH"
and you'll get the default path set at compile time.

Ciao
Giovanni
--
A computer is like an air conditioner,
it stops working when you open Windows.
Registered Linux user #337974 < http://giovanni.homelinux.net/ >

In comp.os.linux.networking Christian Christmann <(E-Mail Removed)>:
> On Mon, 09 Oct 2006 16:05:51 +0200, Giovanni wrote:

>> /usr/X11R6/bin is not in the seach path set by the daemon. Try the command:
>> $ ssh HOSTNAME "/usr/bin/echo \$PATH"
>> and you'll get the default path set at compile time.

What default $PATH and what is compiled?

> Unfortunately, I get

> /bin:/usr/bin:.

> as you assumed.

> Are there any ways to force ssh to use another PATH or
> is a recompilation the only solution?

It has nothing to do with ssh, your $PATH is set from various
shell config files sourced during login, see 'man bash' and read
about INVOCATION for details.

I suspect your $PATH is in one of them mangled if the login isn't
local for whatever reason?

Good luck

--
Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
mail: echo (E-Mail Removed) | perl -pe 'y/a-z/n-za-m/'
#bofh excuse 140: LBNC (luser brain not connected)

In comp.os.linux.networking Christian Christmann <(E-Mail Removed)>:
> On Mon, 09 Oct 2006 22:34:35 +0200, Michael Heiming wrote:

>> It has nothing to do with ssh, your $PATH is set from various
>> shell config files sourced during login, see 'man bash' and read
>> about INVOCATION for details.
>>
>> I suspect your $PATH is in one of them mangled if the login isn't
>> local for whatever reason?

> I acutally mean the ssh PATH that can be also specified as a compiler
> option:

> man ssh:
> (...)
> PATH Set to the default PATH, as specified when compiling ssh.

Yep, but this shouldn't matter to you, the login files of your
shell should reset this to something usable, something is
preventing to reset $PATH while you login via ssh. That's what
I'd check first, it should be easier/faster then recompiling ssh.

--
Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
mail: echo (E-Mail Removed) | perl -pe 'y/a-z/n-za-m/'
#bofh excuse 53: Little hamster in running wheel had coronary;
waiting for replacement to be Fedexed from Wyoming

On Mon, 09 Oct 2006 16:05:51 +0200, Giovanni wrote:

> /usr/X11R6/bin is not in the seach path set by the daemon. Try the command:
> $ ssh HOSTNAME "/usr/bin/echo \$PATH"
> and you'll get the default path set at compile time.

Unfortunately, I get

/bin:/usr/bin:.

as you assumed.

Are there any ways to force ssh to use another PATH or
is a recompilation the only solution?

> Ciao
> Giovanni

Grazie,
Chris

In comp.os.linux.networking Christian Christmann <(E-Mail Removed)>:
> On Mon, 09 Oct 2006 23:10:52 +0200, Michael Heiming wrote:
>
>> Yep, but this shouldn't matter to you, the login files of your
>> shell should reset this to something usable, something is
>> preventing to reset $PATH while you login via ssh. That's what
>> I'd check first, it should be easier/faster then recompiling ssh.

> Again from the ssh man: ;-)

> If command is specified, command is executed on the remote host
> instead of a login shell.

OK, fair point! ;-) Rereading you are remotely staring an xterm,
which must have confused me, I'm still unsure about the purpose
since you can start one local.

xterm -T "remotehost" -e ssh -CXA remotehost

Good luck

--
Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
mail: echo (E-Mail Removed) | perl -pe 'y/a-z/n-za-m/'
#bofh excuse 223: The lines are all busy (busied out, that is --
why let them in to begin with?).

2006-10-09, 15:20(+02), Christian Christmann:
> Hi,
>
> where can I define which initialization scripts are read
> when using ssh?
>
> My problem is that when I login via ssh on a machine, I can
> run "xterm" without any problems. Also
>
> ssh HOSTNAME /usr/X11R6/bin/xterm
>
> works fine. However, when I skip the absolute path and invoke
>
> set HOSTNAME xterm
>
> I get the error message:
> bash: line 1: xterm: command not found
[...]

As your shell seems to be bash, bash has a dirty hack that makes
it read ~/.bashrc when it is called by ssh (IIRC, it checks for
the presence of the SSH_CLIENT or SSH2_CLIENT env var and SHLVL
or whether stdin is a socket...).

So you may want to put your PATH definition there.

If your shell is zsh, use ~/.zshenv.

Best would be to ask your system administrator to setup PATH
correctly on your system.


--
Stéphane

On Mon, 09 Oct 2006 22:34:35 +0200, Michael Heiming wrote:

> It has nothing to do with ssh, your $PATH is set from various
> shell config files sourced during login, see 'man bash' and read
> about INVOCATION for details.
>
> I suspect your $PATH is in one of them mangled if the login isn't
> local for whatever reason?

I acutally mean the ssh PATH that can be also specified as a compiler
option:

man ssh:
(...)
PATH Set to the default PATH, as specified when compiling ssh.

Regards,
Chris

On Mon, 09 Oct 2006 23:10:52 +0200, Michael Heiming wrote:

> Yep, but this shouldn't matter to you, the login files of your
> shell should reset this to something usable, something is
> preventing to reset $PATH while you login via ssh. That's what
> I'd check first, it should be easier/faster then recompiling ssh.

Again from the ssh man: ;-)

If command is specified, command is executed on the remote host
instead of a login shell.