On Mon, 29 May 2000, Joe Stoy <[EMAIL PROTECTED]> wrote:
> I should have known better than to upgrade to the newest rcp.el before
> getting on with my "real" work ...
*grin* After I went to all that effort to put big threatening warnings
into the documentation 'bout precisely this as well. ;)
> 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.
[...]
> The second server was in England. Today is a public holiday, so the
> network is lightly loaded, and the timing is defferent.
[...]
> 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
Bleh. I think that detecting the end of line convention is seriously
broken. The coding system, yes, but the line endings should be fixed. I
think.
[...]
> 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),
That's non-standard enough that you would need to add it to the remote
path yourself, I think. :)
> 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).
Oh. :/
> 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.
I don't think that it can have been truncated by ssh(1) and all. Do you
think that the remote shell couldn't cope with a command line longer
than 255 characters or something?
That would be... painful. I will try splitting the command up though,
and see what happens. Let me know, if you can, how it goes?
Daniel
--
Reality is a collective hunch.
-- Jane Wagner
