I should have known better than to upgrade to the newest rcp.el before
getting on with my "real" work ...
Here are two debug buffers (with irrelevant lines removed), both from
an NT client, both to Solaris servers. The first one is a
transatlantic connection.
--
tcsh: using dumb terminal settings.
stoy@au-bon-pain# Initializing remote shell
$ exec /bin/sh
# Waiting 30s for remote `/bin/sh' to come up...
exec /bin/sh
$ # Setting up remote shell environment
exec /bin/sh
$ stty -echo
# Determining coding system
$ # Detected coding system `undecided' for decoding
# Waiting 30s for `set +o history'
total 185
-rw-r--r-- 1 root 183 Jan 5 15:16 RMAIL
lrwxrwxrwx 1 root9 Dec 8 08:42 bin - ./usr/bin
drwxrwxr-x 11 root 512 Dec 8 14:10 devices
drwxr-xr-x 33 root 4096 Apr 25 08:26 etc
drwxrwxr-x 2 root 512 Dec 16 09:12 export
# Waiting 30s for `unset MAIL MAILCHECK MAILPATH'
drwxr-xr-x 2 root 512 Dec 22 17:11 fs
...
dr-xr-xr-x 6 root 512 Apr 25 08:26 vol
dr-xr-xr-x 1 root1 Apr 25 08:26 xfn
# Waiting for remote `/bin/sh' to come up...done
$ echo ~root
~root
# Looking for remote executable `/bin/ksh'
--
Note that the "exec /bin/sh" gets echoed twice, which puts the
shell-prompt detector out of sync. Thus the coding determiner makes
its decision before any of the directory listing has come. The listing
continues on, and in any symbolic links in it the "-" gets interpreted
as a shell-prompt-pattern, causing the next interaction to start.
However, in this case it all seems to come out right in the end, more
by luck than judgement perhaps.
The second server was in England. Today is a public holiday, so the
network is lightly loaded, and the timing is defferent.
--
Sun Microsystems Inc. SunOS 5.7 Generic October 1998
client2.comlab% # Initializing remote shell
$ exec /bin/sh
# Waiting 30s for remote `/bin/sh' to come up...
exec /bin/sh
$ # Setting up remote shell environment
exec /bin/sh
$ stty -echo
$ # Determining coding system
total 432
lrwxrwxrwx 1 root 13 Aug 16 1999 OPT - /fs/opt-sparc
lrwxrwxrwx 1 root 14 Aug 16 1999 PACK - /fs/pack-sparc
lrwxrwxrwx 1 root 11 Aug 16 1999 archive - /fs/archive
...
drwxrwxr-x 4 root 512 Aug 9 1999 devices
# Detected coding system `undecided-unix' for decoding
# Waiting 30s for `set +o history'
drwxr-xr-x 33 root 3584 May 22 11:33 etc^M
drwxrwxr-x 3 root 512 Aug 9 1999 export^M
...
dr-xr-xr-x 6 root 512 Apr 6 04:01 vol^M
dr-xr-xr-x 2 root 512 Aug 9 1999 xfn^M
$ $ PS1='
/
'; PS2=''; PS3=''
# Waiting for remote `/bin/sh' to come up...
$ $ ^M
/^M
[[INCOMPLETE!]]$ $ ^M
/^M
[[INCOMPLETE!]]
--
So the coding decision is wrong, and ^M's are splattered all over the
place. I've cured that problem for the time being by putting
switch ( $TERM )
case 'cmd':
stty -onlcr ocrnl icrnl
breaksw
default:
breaksw
endsw
into my .login file on the server; I don't know whether that will have
to be a permanent feature. ('cmd' is, as you might guess, the terminal
type produced by the NT ssh client.) It's possible, I suppose, that
the same hack might help Tom Roche on his way...
PERL
The US system didn't have perl in any place rcp.el was clever enough to
find (in fact they were in /map/sys/bin/perl and /map/compat/bin/perl5,
but I don't think I'm going to tell you that), so that was OK. But the
British system did; and my rcp.el jammed up trying to send
rcp_file_attributes (no shell prompt ever received). One possibility
is that there's a shorter buffer involved, and the transmission got
truncated; if so, it'll have to be sent as several chunks, with
continuation lines, I suppose.
j
