rsh problem ...

[Armin_Steinhoff1]

Hi,

there is a curious problem with rsh … the result of a remote cmd
depends
on the string quotes

rsh QRTP_RACK “echo $PATH”

/opt/X11R6/bin:/usr/local/qt/bin:/sbin:/usr/sbin:/proc/boot:/bin:/usr/bin:/usr/l
ocal/bin:/opt/sbin:/opt/vame/ive/bin:/bin:.:/usr/local/lib:/usr/local/bin:/openq
nx/pvm3/lib:/usr/local/lib/python2.2:/usr/X11R6/bin:/usr/X11R6/lib:/openqnx/Pyth
on-2.2/Tools/idle:/openqnx/pvm3/lib/QNX6:/openqnx/pvm3/bin/QNX6:/usr/photon/bin:
/usr/photon/appbuilder

\

rsh QRTP_RACK ‘echo $PATH’

/proc/boot:/bin:/usr/bin

What’s the problem ??

Regards

Armin

[Steve_Reid1]

Armin Steinhoff <a-steinhoff@web_.de> wrote:

: Hi,

: there is a curious problem with rsh … the result of a remote cmd
: depends
: on the string quotes

I don’t think it’s a problem with rsh. The local shell parses the command
line before rsh gets it. The double quotes permit variable substitution,
while the single quotes don’t. For example:

echo “echo $PATH”

results in:

echo /bin:/usr/bin:…

but this:

echo ‘echo $PATH’

results in:

echo $PATH

\

Steve Reid stever@qnx.com
TechPubs (Technical Publications)
QNX Software Systems

[Brian_Stecher1]

Armin Steinhoff <a-steinhoff@web_.de> wrote:

there is a curious problem with rsh … the result of a remote cmd
depends
on the string quotes >

rsh QRTP_RACK “echo $PATH”

…

rsh QRTP_RACK ‘echo $PATH’

…



What’s the problem ??

Absolutely nothing. Try:

echo “echo $PATH”
echo ‘echo $PATH’

Shell quoting rules say that within double quotes, macros are still
expanded. Within single quotes, they aren’t. That means in your first
example, the $PATH is expanded on the local machine. In the second, the
$PATH is not expanded on the local machine, but when it gets to the
remote it is (since the quotes have been processed and removed by the
local shell).

You can delay the expansion to the remote machine by also doing something
like:

rsh QRTP_RACK “echo $PATH”

–
Brian Stecher (bstecher@qnx.com) QNX Software Systems, Ltd.
phone: +1 (613) 591-0931 (voice) 175 Terence Matthews Cr.
+1 (613) 591-3579 (fax) Kanata, Ontario, Canada K2M 1W8

[Armin2]

Brian Stecher wrote:

Armin Steinhoff <a-steinhoff@web_.de> wrote:

there is a curious problem with rsh … the result of a remote cmd
depends
on the string quotes >

\

rsh QRTP_RACK “echo $PATH”

…

\

rsh QRTP_RACK ‘echo $PATH’

…


What’s the problem ??


Absolutely nothing.

You haven’t read care fully my posting …

Try:

echo “echo $PATH”
echo ‘echo $PATH’

Shell quoting rules say that within double quotes, macros are still
expanded. Within single quotes, they aren’t. That means in your first
example, the $PATH is expanded on the local machine. In the second, the
$PATH is not expanded on the local machine,

It is expanded on the remote machine … but the environment is wrong.
Well trust your eyes … or do your own tests.

That’s are the facts: # rsh QRTP_RACK ‘echo $PATH’
returns → /proc/boot:/bin:/usr/bin … but this
is not the PATH which fits to the environment
of the remote login.

It is not a shell problem. I have used bash and got the same behavior
of the rsh command.

but when it gets to the
remote it is (since the quotes have been processed and removed by the
local shell).

You can delay the expansion to the remote machine by also doing something
like:

rsh QRTP_RACK “echo $PATH”

There are no problems with rsh QRTP_RACK “echo $PATH” … it works
correctly.

Regards

Armin

[LiuG3]

It actually is supposed to work that way Armin.
When you login to a box, your /etc/profile and .profile will
get sourced (with /bin/sh as login shell). But when you using rsh
to run a command without actually login to the remote box,
it will launch a shell to do that. This is similiar to when
you bring up an xterm or pterm locally. It will NOT source the
profiles. This means
rsh remote ‘echo $PATH’
will NOT show any PATH that are set in your /etc/profile and/or .profile.

I know when csh/tcsh, you can create a .cshrc file which will be sourced
for every new instance of the shell. Supposedly you can do the same thing
with .kshrc for ksh, or .bashrc for bash, but I never get it reliably worked.

btw, when you do
rsh remote “echo $PATH”
you are actually echoing the PATH on your local box, as other people
have pointed out. You can verify this by temperarily changing your local
PATH and run that rsh command to see…

Frank

Armin <a-steinhoff@web_.de> wrote:

Brian Stecher wrote:
Armin Steinhoff <a-steinhoff@web_.de> wrote:

there is a curious problem with rsh … the result of a remote cmd
depends
on the string quotes >

\

rsh QRTP_RACK “echo $PATH”

…

\

rsh QRTP_RACK ‘echo $PATH’

…


What’s the problem ??


Absolutely nothing.

You haven’t read care fully my posting …

Try:

echo “echo $PATH”
echo ‘echo $PATH’

Shell quoting rules say that within double quotes, macros are still
expanded. Within single quotes, they aren’t. That means in your first
example, the $PATH is expanded on the local machine. In the second, the
$PATH is not expanded on the local machine,



It is expanded on the remote machine … but the environment is wrong.
Well trust your eyes … or do your own tests.

That’s are the facts: # rsh QRTP_RACK ‘echo $PATH’
returns → /proc/boot:/bin:/usr/bin … but this
is not the PATH which fits to the environment
of the remote login.

It is not a shell problem. I have used bash and got the same behavior
of the rsh command.

but when it gets to the
remote it is (since the quotes have been processed and removed by the
local shell).

You can delay the expansion to the remote machine by also doing something
like:

rsh QRTP_RACK “echo $PATH”



There are no problems with rsh QRTP_RACK “echo $PATH” … it works
correctly.

Regards

Armin



–
===========================================
My public key can be found at
http://mama.indstate.edu/users/liug/key.txt

[David_Gibbs1]

Armin <a-steinhoff@web_.de> wrote:

Brian Stecher wrote:

Armin Steinhoff <a-steinhoff@web_.de> wrote:

there is a curious problem with rsh … the result of a remote cmd
depends
on the string quotes >

\

rsh QRTP_RACK “echo $PATH”

…

\

rsh QRTP_RACK ‘echo $PATH’

…


What’s the problem ??


Absolutely nothing.

You haven’t read care fully my posting …

You haven’t understood what is happening.

Try:

echo “echo $PATH”
echo ‘echo $PATH’

Shell quoting rules say that within double quotes, macros are still
expanded. Within single quotes, they aren’t. That means in your first
example, the $PATH is expanded on the local machine. In the second, the
$PATH is not expanded on the local machine,



It is expanded on the remote machine … but the environment is wrong.
Well trust your eyes … or do your own tests.

That isn’t what you said – you didn’t say that remote environment
was wrong, you just posted something that showed that the local and
remote environment were different.

That’s are the facts: # rsh QRTP_RACK ‘echo $PATH’
returns → /proc/boot:/bin:/usr/bin … but this
is not the PATH which fits to the environment
of the remote login.

Ah, that is a different issue – not what you initially posted.

rsh does NOT create a login shell on the remote machine. Therefor,
you will not get processing of /etc/profile and ~/.profile where
PATHs are usually set. You will get whatever path is inheritted from
io-net, probably started in boot file or soon after, that is, a
fairly minimal path.

It is not a shell problem. I have used bash and got the same behavior
of the rsh command.

It is not a shell problem. It is proper behaviour of the shell, from the
bourne sh (both ksh and bash are derivatives of sh), which is why bash
also gives the same behaviour.

but when it gets to the
remote it is (since the quotes have been processed and removed by the
local shell).

You can delay the expansion to the remote machine by also doing something
like:

rsh QRTP_RACK “echo $PATH”

There are no problems with rsh QRTP_RACK “echo $PATH” … it works
correctly.

It gives you the path on your local machine.

Before you do the double-quote version, try doing this:

export PATH=$PATH:/dir_not_in_path
rsh QRTP_RACK “echo $PATH”

You’ll find that it has /dir_not_in_path in its path.

-David

QNX Training Services
I do not answer technical questions by email.

[Armin_Steinhoff1]

David Gibbs wrote:

You haven’t understood what is happening.

I’m not convienced Please read my initial posting!!

Try:

echo “echo $PATH”
echo ‘echo $PATH’

Try it locally:

sh “echo $Path” and sh echo $PATH → it works
sh ‘echo $PATH’ → it doesn’t work
(take care about ’ and `)

and now remotely:

rsh QRTP_RACK “echo $PATH” → it works
rsh QRTP_RACK ‘echo $PATH’ → it works, but the result isn’t
correct

SO … what is the problem with the string interpretation at
the remote side???

Best Regards

Armin

Shell quoting rules say that within double quotes, macros are still
expanded. Within single quotes, they aren’t. That means in your first
example, the $PATH is expanded on the local machine. In the second, the
$PATH is not expanded on the local machine,

It is expanded on the remote machine … but the environment is wrong.
Well trust your eyes … or do your own tests.

That isn’t what you said – you didn’t say that remote environment
was wrong, you just posted something that showed that the local and
remote environment were different.

That’s are the facts: # rsh QRTP_RACK ‘echo $PATH’
returns → /proc/boot:/bin:/usr/bin … but this
is not the PATH which fits to the environment
of the remote login.

Ah, that is a different issue – not what you initially posted.

rsh does NOT create a login shell on the remote machine. Therefor,
you will not get processing of /etc/profile and ~/.profile where
PATHs are usually set. You will get whatever path is inheritted from
io-net, probably started in boot file or soon after, that is, a
fairly minimal path.

It is not a shell problem. I have used bash and got the same behavior
of the rsh command.

It is not a shell problem. It is proper behaviour of the shell, from the
bourne sh (both ksh and bash are derivatives of sh), which is why bash
also gives the same behaviour.

but when it gets to the
remote it is (since the quotes have been processed and removed by the
local shell).

You can delay the expansion to the remote machine by also doing something
like:

rsh QRTP_RACK “echo $PATH”

There are no problems with rsh QRTP_RACK “echo $PATH” … it works
correctly.

It gives you the path on your local machine.

Before you do the double-quote version, try doing this:

export PATH=$PATH:/dir_not_in_path
rsh QRTP_RACK “echo $PATH”

You’ll find that it has /dir_not_in_path in its path.

-David

QNX Training Services
I do not answer technical questions by email.

[Armin_Steinhoff1]

Hi Frank,

sorry I saw your useful message too late …

LiuG wrote:

It actually is supposed to work that way Armin.
When you login to a box, your /etc/profile and .profile will
get sourced (with /bin/sh as login shell). But when you using rsh
to run a command without actually login to the remote box,
it will launch a shell to do that. This is similiar to when
you bring up an xterm or pterm locally. It will NOT source the
profiles. This means
rsh remote ‘echo $PATH’
will NOT show any PATH that are set in your /etc/profile and/or .profile.

I know when csh/tcsh, you can create a .cshrc file which will be sourced
for every new instance of the shell. Supposedly you can do the same thing
with .kshrc for ksh, or .bashrc for bash, but I never get it reliably worked.

I will give it a try.

btw, when you do
rsh remote “echo $PATH”
you are actually echoing the PATH on your local box,

Why ? the string “echo $Path” represents a remotr cmd … or??

as other people have pointed out.

Was too weired to believe

You can verify this by temperarily >changing your local PATH and run >that rsh command to see…

I will check it also on a LINUX box.

Thanks for your reply.

Regards

Armin

Frank

Armin <a-steinhoff@web_.de> wrote:
Brian Stecher wrote:
Armin Steinhoff <a-steinhoff@web_.de> wrote:

there is a curious problem with rsh … the result of a remote cmd
depends
on the string quotes >

\

rsh QRTP_RACK “echo $PATH”

…

\

rsh QRTP_RACK ‘echo $PATH’

…


What’s the problem ??


Absolutely nothing.

You haven’t read care fully my posting …

Try:

echo “echo $PATH”
echo ‘echo $PATH’

Shell quoting rules say that within double quotes, macros are still
expanded. Within single quotes, they aren’t. That means in your first
example, the $PATH is expanded on the local machine. In the second, the
$PATH is not expanded on the local machine,

It is expanded on the remote machine … but the environment is wrong.
Well trust your eyes … or do your own tests.

That’s are the facts: # rsh QRTP_RACK ‘echo $PATH’
returns → /proc/boot:/bin:/usr/bin … but this
is not the PATH which fits to the environment
of the remote login.

It is not a shell problem. I have used bash and got the same behavior
of the rsh command.

but when it gets to the
remote it is (since the quotes have been processed and removed by the
local shell).

You can delay the expansion to the remote machine by also doing something
like:

rsh QRTP_RACK “echo $PATH”

There are no problems with rsh QRTP_RACK “echo $PATH” … it works
correctly.

Regards

Armin



\

===========================================
My public key can be found at
http://mama.indstate.edu/users/liug/key.txt

[David_Gibbs1]

Armin Steinhoff <a-steinhoff@web_.de> wrote:

David Gibbs wrote:


You haven’t understood what is happening.

I’m not convienced > > Please read my initial posting!!

I did.

Try:

echo “echo $PATH”
echo ‘echo $PATH’

Try it locally:

sh “echo $Path” and sh echo $PATH → it works

Didn’t for me. I got:

sh: echo /sbin:/usr/sbin:/proc/boot/bin:/bin:/usr/bin:/usr/local/bin: No
such file or directory

For both of the above.

sh ‘echo $PATH’ → it doesn’t work

sh:echo $PATH: No such file or directory

Which also illustrates what is going. The shell you typed into
expand $PATH in the first case, but not in the second.

So, in the first case, the sh you ran got an argv[1] of something
like “echo /sbin:/usr/sbin:/proc/boot/bin:…” and failed to find
that executable. (In the " " case, it was expanded by the shell,
it the case, the command “echo $PATH” was run and the stdout
from it was substituted.)

In the second case, it got an argv[1] of something like
“echo $PATH”, and it still failed to find such an executable.

In NEITHER case did a seperate sh run echo to display anything.

(take care about ’ and `)

and now remotely:

rsh QRTP_RACK “echo $PATH” → it works

It doesn’t work. It expands $PATH locally, then echos that from
the remote side.

rsh QRTP_RACK ‘echo $PATH’ → it works, but the result isn’t
correct

It works, and gives the correct path for a remotely shelled environment.

SO … what is the problem with the string interpretation at
the remote side???

The string markers are not getting to the other side. They are
evaluated by the shell where you typed the command in.

It gives you the path on your local machine.

Before you do the double-quote version, try doing this:

export PATH=$PATH:/dir_not_in_path
rsh QRTP_RACK “echo $PATH”

You’ll find that it has /dir_not_in_path in its path.

Try the above.

-David

QNX Training Services
I do not answer technical questions by email.

[David_Gibbs1]

Armin Steinhoff <a-steinhoff@web_.de> wrote:

Hi Frank,

btw, when you do
rsh remote “echo $PATH”
you are actually echoing the PATH on your local box,

Why ? the string “echo $Path” represents a remotr cmd … or??

No. It represents something to the shell that you typed the command
into. The shell parses it.

It looks at the pair of " and says… ah, don’t treat spaces inside
there as token seperators (essentially).

It then expands $PATH (because it recognised that as a shell variable).

it then does something like:

spawnl(P_WAIT, “rsh”, “rsh”, “remote”, “echo dir:dir:dir:dir”, NULL );

the other case:

rsh remote ‘echo $PATH’

Well, the ’ says to not expand macro definitions, and not treat spaces
as tokenizing. So the shell does something like:

spawnl(P_WAIT, “rsh”, “rsh”, “remote”, “echo $PATH”, NULL );

as other people have pointed out.

Was too weired to believe >

Some shell behaviour is a bit wierd.

-David

QNX Training Services
I do not answer technical questions by email.

[Armin_Steinhoff1]

David Gibbs wrote:

[ clip …]
Try it locally:

sh “echo $Path” and sh echo $PATH → it works

Didn’t for me. I got:

sh: echo /sbin:/usr/sbin:/proc/boot/bin:/bin:/usr/bin:/usr/local/bin: No
such file or directory

Hm … overlooked the begin (echo) and trailer. You are right.

[ clipp …]

and now remotely:

rsh QRTP_RACK “echo $PATH” → it works

It doesn’t work. It expands $PATH locally, then echos that from
the remote side.

Yes … rsh will be processed, but the result is wrong.
I saw it also after a hint from Frank.

rsh QRTP_RACK ‘echo $PATH’ → it works, but the result isn’t
correct

It works, and gives the correct path for a remotely shelled environment.

IMHO the rsh is also using the rcmd call. One of the actual parameters
of rcmd is
the user name and the remote cmd. “cmd xy” leads to ““cmd xy”” and
‘cmd xy’ leads to “‘cmd xy’” as an actual command string.

The evaluation of “‘cmthd xy’” seems to be done at the remote side
without
respecting the specification of the user name … this happens also when
you
specify the user name with the -l option.

SO … what is the problem with the string interpretation at
the remote side???

The string markers are not getting to the other side. They are
evaluated by the shell where you typed the command in.

That would be the correct behavior …

Thanks

Armin

[Armin_Steinhoff1]

David Gibbs wrote:

Armin Steinhoff <a-steinhoff@web_.de> wrote:
Hi Frank,

btw, when you do
rsh remote “echo $PATH”
you are actually echoing the PATH on your local box,

Why ? the string “echo $Path” represents a remotr cmd … or??

No. It represents something to the shell that you typed the command
into. The shell parses it.

It looks at the pair of " and says… ah, don’t treat spaces inside
there as token seperators (essentially).

It then expands $PATH (because it recognised that as a shell variable).

it then does something like:

spawnl(P_WAIT, “rsh”, “rsh”, “remote”, “echo dir:dir:dir:dir”, NULL );

the other case:

rsh remote ‘echo $PATH’

Well, the ’ says to not expand macro definitions, and not treat spaces
as tokenizing. So the shell does something like:

spawnl(P_WAIT, “rsh”, “rsh”, “remote”, “echo $PATH”, NULL );

as other people have pointed out.

Was too weired to believe >

Some shell behaviour is a bit wierd.

Thanks a lot … the semantic of ’ and " is now clear.
BTW … the bash of LINUX works in the same way.


Regards

Armin

-David

QNX Training Services
I do not answer technical questions by email.

[Alain_Magloire]

Armin Steinhoff <a-steinhoff@web_.de> wrote:


: David Gibbs wrote:
:>
:> Armin Steinhoff <a-steinhoff@web_.de> wrote:

…

: Thanks a lot … the semantic of ’ and " is now clear.
: BTW … the bash of LINUX works in the same way.

That is the way it should work for any (bourne, …) shell on
any Un*x. If it does not it should be consider as a bug.

A general note:

People coming from a non Un*x background has difficulty with
this: the expansion is done by the shell not the program.
and vice versa i.e. I think on Windows the expansion is done
by the program

[Armin_Steinhoff1]

Alain Magloire wrote:

Armin Steinhoff <a-steinhoff@web_.de> wrote:

: David Gibbs wrote:
:
:> Armin Steinhoff <a-steinhoff@web_.de> wrote:

…

: Thanks a lot … the semantic of ’ and " is now clear.
: BTW … the bash of LINUX works in the same way.

That is the way it should work for any (bourne, …) shell on
any Un*x. If it does not it should be consider as a bug.

A general note:

People coming from a non Un*x background has difficulty with
this: the expansion is done by the shell not the program.
and vice versa i.e. I think on Windows the expansion is done
by the program

OK … well, I’m not a shell guy

So my correct rsh command should be: rsh remote_host -l root ‘echo
$ENV_VAR’

In the the rshd docs is written:

9. A NULL byte is returned on the initial socket and the command line is
   passed to the normal login shell of the user.

---

The user is root and ENV_VAR has been exported into the login shell of
root … but
rsh looks into a different shell environment.

That’s my big problem!!

In which environment must the ENV_VAR exported just in order to
have access to it remotely ???

Regards

Armin

[Alain_Magloire]

Armin Steinhoff <a-steinhoff@web_.de> wrote:


: Alain Magloire wrote:
:>
:> Armin Steinhoff <a-steinhoff@web_.de> wrote:
:>
:> : David Gibbs wrote:
:> :>
:> :> Armin Steinhoff <a-steinhoff@web_.de> wrote:
:>

…

: OK … well, I’m not a shell guy

: So my correct rsh command should be: rsh remote_host -l root ‘echo
: $ENV_VAR’

: In the the rshd docs is written:
: ---------------------------------------------------------------------------
: 9. A NULL byte is returned on the initial socket and the command line is
: passed to the normal login shell of the user.
: ---------------------------------------------------------------------------

: The user is root and ENV_VAR has been exported into the login shell of
: root … but
: rsh looks into a different shell environment.

: That’s my big problem!!

: In which environment must the ENV_VAR exported just in order to
: have access to it remotely ???


Another gotcha.

When doing rsh, the login procedure is not the same. Since this is not
an interactive shell your usual .profile .bashrc etc … is not
source. So if you try

rsh remote_host ‘env’

You will see that the number of environment variables are quite limited i.e.
not the same when you do a normal login session.

I do not know what you are trying to achieve but,
you may, if you want, dance around things:

rsh remote_host ‘. $HOME/.profile; echo $PATH’

assuming you are using /bin/sh and you have a .profile does not contain
interactive commands like: stty etc … which needs pty’s.


Before you ask:
On some systems doing rsh -l root … maybe prohibited for security
reasons. For example some versions of rshd/rlogind from GNU inetutils will
just close connection … very rude.

[LiuG3]

Alain Magloire <alain@qnx.com> wrote:

When doing rsh, the login procedure is not the same. Since this is not
an interactive shell your usual .profile .bashrc etc … is not
source. So if you try

not exactly true. at least for csh/tcsh, you have .login (similiar to
…profile) and .cshrc (similiar to .bashrc/.kshrc), the .login is sourced
for an interactive login, .cshrc is sourced for non login shells.
(such as bringing up an xterm). I tried Armin’s rsh with PATH set in
the .cshrc on the remote box and it did show up with echo.

as mentioned in my previous post, I never able to get .bashrc/.kshrc
to work. now I am even confused about the functionality of those rc files.
It seems you have to set something like ENV=.kshrc in .profile before
it can work. But if your .profile isn’t sourced (for rsh) …

frank

[Armin_Steinhoff1]

Alain Magloire wrote:

[ clipp …]
: So my correct rsh command should be: rsh remote_host -l root ‘echo $ENV_VAR’

: In the the rshd docs is written:
: ---------------------------------------------------------------------------
: 9. A NULL byte is returned on the initial socket and the command line is
: passed to the normal login shell of the user.
: ---------------------------------------------------------------------------

: The user is root and ENV_VAR has been exported into the login shell of
: root … but rsh looks into a different shell environment.

: That’s my big problem!!

: In which environment must the ENV_VAR exported just in order to
: have access to it remotely ???

Another gotcha.

When doing rsh, the login procedure is not the same. Since this is not
an interactive shell your usual .profile .bashrc etc … is not
source.

No I’m not convienced. Here is an other description of rshd:

11.rshd → loads the user’s profile ← and runs the command specified in
the
user’s home directory.

rshd first checks to see if the SHELL environment variable is set and if
so, that shell is used to run the command. If SHELL is not set, rshd
checks the …

If the behavior of the QNX6 version of rshd would be standard … no
cluster middleware would run with rsh/rshd on other UNIX like systems.

But there are more than 40 working implementations in the field!!

So if you try

rsh remote_host ‘env’

You will see that the number of environment variables are quite limited i.e.
not the same when you do a normal login session.

I do not know what you are trying to achieve but,
you may, if you want, dance around things:

No, no … you are dancing around the problem.

rsh/rshd is broken … I will give Open SSH a try and will do a port of
the GNU inetutils.

Regards

Armin

[Alain_Magloire]

Armin Steinhoff <a-steinhoff@web_.de> wrote:


: Alain Magloire wrote:
:>
:>

[ clip ]

:>
:> When doing rsh, the login procedure is not the same. Since this is not
:> an interactive shell your usual .profile .bashrc etc … is not
:> source.

: No I’m not convienced. Here is an other description of rshd:
: ----------------------------------------------------------------------------------------------
: 11.rshd → loads the user’s profile ← and runs the command specified in
: the
: user’s home directory.

: rshd first checks to see if the SHELL environment variable is set and if
: so, that shell is used to run the command. If SHELL is not set, rshd
: checks the …
: ---------------------------------------------------------------------------------------------

: If the behavior of the QNX6 version of rshd would be standard … no

First what is standard? There is a formal RFC that defines rlogin protocol
rfc1282. But in term of standard, you can only rely on the BSD code.

Try it on other platforms like say solaris with bash/sh as the
default shell and tell me if there are differences.

QNX6 rsh/rshd is the BSD source code. Albeit base on 4.3BSD which may show
its age.

: But there are more than 40 working implementations in the field!!

Most of them are base on the BSD code and share the same functionnalities/bugs

:> So if you try
:>
:> rsh remote_host ‘env’
:>
:> You will see that the number of environment variables are quite limited i.e.
:> not the same when you do a normal login session.
:>
:> I do not know what you are trying to achieve but,
:> you may, if you want, dance around things:

: No, no … you are dancing around the problem.

Yes I am, I offered alternative solutions to your problem.


: rsh/rshd is broken … I will give Open SSH a try and will do a port of
: the GNU inetutils.

The GNU inetutils port is the BSD code, you will find the same behaviour.
But if you ever want to take a look, I would recommand the snapshots on
ftp://alpha.gnu.org/gnu/inetutils
Those snapshots take care of some obvious security holes, I beleive
some of the daemon were rewritten but not rshd.

[Alain_Magloire]

LiuG <liug@mama.indstate.edu> wrote:
: Alain Magloire <alain@qnx.com> wrote:
:> When doing rsh, the login procedure is not the same. Since this is not
:> an interactive shell your usual .profile .bashrc etc … is not
:> source. So if you try

: not exactly true. at least for csh/tcsh, you have .login (similiar to
: .profile) and .cshrc (similiar to .bashrc/.kshrc), the .login is sourced
: for an interactive login, .cshrc is sourced for non login shells.
: (such as bringing up an xterm). I tried Armin’s rsh with PATH set in
: the .cshrc on the remote box and it did show up with echo.

You cut one important line from my post:
" Assuming you are using bourne shell as your default shell"

Shell behaviours are different, “all” rshd is doing is, after
doing auth, setting the pipe()s, fork() etc … it ends doing:

{
…
execl (pwd->pw_shell, cp, “-c”, cmdbuf, 0);
perror (pwd->pw_shell);
exit (1);
}

Depending on your default shell the behaviour will differ.


: as mentioned in my previous post, I never able to get .bashrc/.kshrc
: to work. now I am even confused about the functionality of those rc files.
: It seems you have to set something like ENV=.kshrc in .profile before
: it can work. But if your .profile isn’t sourced (for rsh) …

I’ve never use ksh, so do not know. You will have to read the man
pages for it … wait I got a solaris box handy … let me cut and paste:

ENV This variable, when the shell is invoked, is subjected
to parameter expansion by the shell and the resulting
value is used as a pathname of a file containing shell
commands to execute in the current environment. The
file need not be executable. If the expanded value of
ENV is not an absolute pathname, the results are
unspecified. ENV will be ignored if the user’s real
and effective user IDs or real and effective group IDs
are different.

This variable can be used to set aliases and other
items local to the invocation of a shell. The file
referred to by ENV differs from $HOME/.profile in
that .profile is typically executed at session
startup, whereas the ENV file is executed at the
beginning of each shell invocation. The ENV value is
interpreted in a manner similar to a dot script, in
that the commands are executed in the current environ-
ment and the file needs to be readable, but not exe-
cutable. However, unlike dot scripts, no PATH search-
ing is performed. This is used as a guard against Tro-
jan Horse security breaches.


Now … I beleive we ship, ksh93 or something similar, it may not
map one to one as Solaris ships the /usr/xpg4/bin/ksh.

[Armin_Steinhoff1]

Alain Magloire wrote:

Armin Steinhoff <a-steinhoff@web_.de> wrote:

[ clipp…]
First what is standard? There is a formal RFC that defines rlogin protocol
rfc1282. But in term of standard, you can only rely on the BSD code.

Try it on other platforms like say solaris with bash/sh as the
default shell and tell me if there are differences.

QNX6 rsh/rshd is the BSD source code. Albeit base on 4.3BSD which may show
its age.

Yes … the rshd code of the inetutil-1.3.2 distribution is BSD based.

: But there are more than 40 working implementations in the field!!

Most of them are base on the BSD code and share the same functionnalities/bugs

But they are woking … why??

Yes I am, I offered alternative solutions to your problem.

Many thanks for your proposals … but they wasn’t applicable.

: rsh/rshd is broken … I will give Open SSH a try and will do a port of
: the GNU inetutils.

The GNU inetutils port is the BSD code, you will find the same behaviour.

I did a plain re-compilation of 1.3.2 distribution (no single char
changed) and
the executable WORKS as expected!!

The new(?) rshd is available at http://www.sf.net/projects/openqnx …
PVM 3.4.4 release.

But if you ever want to take a look, I would recommand the snapshots on
ftp://alpha.gnu.org/gnu/inetutils
Those snapshots take care of some obvious security holes, I beleive
some of the daemon were rewritten but not rshd.

Yes, I’m aware about the security wholes of rsh … for that reason I
will test at next the OpenSSH stuff.

Many thanks for your feedback!

Regards

Armin