Re: tramp (2.1.2); confusing failure mode when remote host does not give ssh prompt

[Alan Donovan]

On Mon, Oct 09, 2006 at 11:01:53PM +0200, Michael Albinus wrote:
> Alan Donovan <address@hidden> writes:
>
> Hi,
>
> > When evaluating the following expression:
> >
> >      (tramp-handle-file-exists-p "/foo.yoyodyne.com:/bar.cc")
> >
> > using the "ssh" access method, where "foo" is a host that responds to
> > pings, and accepts incoming ssh connections, but does not respond with
> > a "Password:" prompt in a timely manner, then the evaluation fails
> > with the following stack trace:
> >
> > Debugger entered--Lisp error: (wrong-type-argument stringp nil)
> >   format(nil "/foo.java")
> >   (tramp-send-command-and-check multi-method method user host (format
> >     (tramp-get-file-exists-command multi-method method user host)
> >     (tramp-shell-quote-argument path)))
>
> Are you sure we're speaking about Tramp 2.1.2? According to the
> ChangeLog, multi-method has been removed since Tramp 2.1.1.
>
> > Ideally in such cases the code should signal some kind of timeout
> > error such as "host 'foo' not responding to ssh connection".
>
> More recent Tramp versions (like 2.1.7) show the contents of the
> connection buffer in case of an error. This is intended to give more
> information about the problem.
>
> Could you, please, check whether this is sufficient for your needs?
>
> > cheers
> > alan
>
> Best regards, Michael.


Thanks for your swift response, and sorry for the confusing error
report.  I've double-checked and I think you are correct; I was using
2.0.22 when I discovered the problem, and I upgraded to 2.1.2 which
exhibited similar behaviour, but I did not change the stack-trace I'd
yanked into my e-mail.  The updated stack-trace from 2.1.2 is as
follows:

Debugger entered--Lisp error: (wrong-type-argument stringp nil)
  format(nil "/bar.cc")
  tramp-handle-file-exists-p("/foo.yoyodyne.com:/bar.cc")
  eval((tramp-handle-file-exists-p "/foo.yoyodyne.com:/bar.cc"))
  eval-last-sexp-1(nil)
  eval-last-sexp(nil)
  call-interactively(eval-last-sexp)

I tried 2.1.7 and it does indeed produce better error messages, so
I'll use that instead.  Thanks again, and sorry for being so lame.

alan