dtksh vs ksh behavior

[gdemers]

The following script loop sequence works with dtksh but exits after one iteration with /usr/bin/ksh. Any thoughts

#!/usr/dt/bin/dtksh
cat /usr/local/prod/data/prod_hp_server_list.txt|while read nm
do

if [[ "B.11.31" != "$(ssh $nm uname -r)" ]]
then
echo "Host $nm is $(ssh $nm uname -r)"
else
echo "Host $nm is 31"
fi

done

[Steven Schweda]

I don't know why the two shells work
differently, but one thing I wouldn't do in
my script is run the "ssh" job twice to get
the same result in two places.

rem_ver="$(ssh $nm uname -r)"

Then test and/or display "rem_ver".

I don't know if it would help, but you might
try something more like:

(
while read nm
[...]
) < /.../prod_hp_server_list.txt

[James R. Ferguson]

Hi:

Two comments. The HP 'ksh' shell is a Korn88 shell whereas the 'dtksh' is based on Korn93. This is true at least the last time I looked.

Secondly, you would be advised to add '-n' to your remote command:

# ssh -n $nm uname -r

Regards!

...JRF...

[gdemers]

I agree with your suggestions but neither explains the behavior. I believe that code snippet should work with ksh88.

[Mel Burslan]

in my experience, this, i.e., ssh into a remote server while looping through the server names in a `while read` command, never worked.

something strange happens to the read buffers when you remote ssh into a server and come back to the same shell. I can not think of any reason why but as if, when you go out to the remote system, your local read buffers get flushed out. Hence when you return, there is nothing in the buffer to loop through. No logical explanation though.

[Michael Steele_2 · Accepted solution]

Works for me with the -n option in ssh as pointed out by JRF

if [[ "B.11.31" != "$(ssh $nm -n "uname -r")" ]]

pitt20-/root/mfs: r .
./mfs
Host fxgip34 is 31
Host fxgip35 is 31
Host fxgip36 is 31

[Michael Steele_2]

I have assigned points to 5 of 25 responses

Could you make sure you're assigning points to resposnes as indicated in the rules of the forum

thanks

[Michael Steele_2]

BTW, I would speculate to say that you don't have a shell to shell problem but a ssh version to ssh version problem.