tramp

tramp

[Miles Bader]

Is tramp in the current emacs CVS (2002-08-02) supposed to work?

I've tried a bunch of different filenames, and invariably tramp gets
confused and just hangs waiting for a prompt or something.  When I use
^G to interrupt it, and look at the `*tramp...*' buffer, I see a shell
prompt (but apparently tramp never realized it).


For instance, visiting:

`/sudo:root@localhost:/etc':

   Shows the following messages:

      tramp: Opening connection for `root' using `sudo'...
      tramp: Processing actions
      tramp: Waiting 60s for prompt from remote shell
      tramp: Looking for pattern ^.*\([pP]assword\|passphrase.*\):
      tramp: Looking for pattern .*ogin: *
      tramp: Looking for pattern ^\(([^) 	]*)\|[^> 	]*[>]\)\s-*
      tramp: Found remote shell prompt.
      tramp: Waiting 30s for remote `/bin/sh' to come up...
      Quit

  [Seeing `Found remote shell prompt' immediately followed by 
   `Waiting 30s for remote `/bin/sh' to come up' seems ... odd.]

  Looking in the `*tramp/sudo root@localhost*' buffer, I see:

     sh-2.05b# 


`/su:root@localhost:/etc':

   Shows the following messages:

      tramp: Opening connection for `root' using `su'...
      tramp: Processing actions
      tramp: Waiting 60s for prompt from remote shell
      tramp: Looking for pattern ^.*\([pP]assword\|passphrase.*\):
      Password: 
      Password: .
      Password: ..
      Password: .......
      tramp: Looking for pattern .*ogin: *
      tramp: Looking for pattern ^\(([^) 	]*)\|[^> 	]*[>]\)\s-*
      tramp: Looking for pattern ^.*\(Permission denied.\|Login [Ii]ncorrect\|Received signal [0-9]+\|Connection \(refused\|closed\)\|Sorry, try again.\|Name or service not known\).*
      tramp: Looking for pattern Are you sure you want to continue connecting (yes/no)\? *
      tramp: Looking for pattern ^.*\([pP]assword\|passphrase.*\):
      tramp: Looking for pattern .*ogin: *
      tramp: Looking for pattern ^\(([^) 	]*)\|[^> 	]*[>]\)\s-*
      tramp: Looking for pattern ^.*\(Permission denied.\|Login [Ii]ncorrect\|Received signal [0-9]+\|Connection \(refused\|closed\)\|Sorry, try again.\|Name or service not known\).*
      tramp: Looking for pattern Are you sure you want to continue connecting (yes/no)\? *
      tramp: Looking for pattern ^.*\([pP]assword\|passphrase.*\):
      tramp: Looking for pattern .*ogin: *
      tramp: Looking for pattern ^\(([^) 	]*)\|[^> 	]*[>]\)\s-*
      tramp: Looking for pattern ^.*\(Permission denied.\|Login [Ii]ncorrect\|Received signal [0-9]+\|Connection \(refused\|closed\)\|Sorry, try again.\|Name or service not known\).*
      tramp: Looking for pattern Are you sure you want to continue connecting (yes/no)\? *
      Quit

   [Note that even though the above appears as if it's asking a user
    question, it doesn't seem to accept any input; I have to interrupt
    it to do anything]

   Looking in the `*tramp/su root@localhost*' buffer, I see:


      mcspd15:~# 

   [that's a blank line at the beginning].


Trying to use the `ssh' method to connect to `fp-ssh.gnu.org' gives
similar results to the latter, but without the password prompt (I have
ssh setup to not require a password).

Thanks,

-Miles

-- 
`...the Soviet Union was sliding in to an economic collapse so comprehensive
 that in the end its factories produced not goods but bads: finished products
 less valuable than the raw materials they were made from.'  [The Economist]

Re: tramp

[Kai Großjohann]

Miles Bader <miles@lsi.nec.co.jp> writes:

> Is tramp in the current emacs CVS (2002-08-02) supposed to work?
>
> I've tried a bunch of different filenames, and invariably tramp gets
> confused and just hangs waiting for a prompt or something.  When I use
> ^G to interrupt it, and look at the `*tramp...*' buffer, I see a shell
> prompt (but apparently tramp never realized it).

Yes, I think so.

> For instance, visiting:
>
> `/sudo:root@localhost:/etc':
>
>    Shows the following messages:
>
>       tramp: Opening connection for `root' using `sudo'...
>       tramp: Processing actions
>       tramp: Waiting 60s for prompt from remote shell
>       tramp: Looking for pattern ^.*\([pP]assword\|passphrase.*\):
>       tramp: Looking for pattern .*ogin: *
>       tramp: Looking for pattern ^\(([^) 	]*)\|[^> 	]*[>]\)\s-*

This looks like your shell-prompt-pattern.  Is it?

>       tramp: Found remote shell prompt.
>       tramp: Waiting 30s for remote `/bin/sh' to come up...
>       Quit
>
>   [Seeing `Found remote shell prompt' immediately followed by 
>    `Waiting 30s for remote `/bin/sh' to come up' seems ... odd.]

Heh :-)  First, Tramp logs in to the remote system and waits for any
old shell prompt.  But for proper operation, Tramp needs a Bourneish
shell, so it issues "exec /bin/sh" first thing.  Of course, after
this Tramp again has to wait for a shell prompt...

Maybe I should make this clearer in the messages.  But how?

>   Looking in the `*tramp/sudo root@localhost*' buffer, I see:
>
>      sh-2.05b# 

At this point, Tramp is again waiting for shell-prompt-pattern, and
this shell prompt does not match the regexp above.

Could this be the case?

It used to be that Tramp tried to grok some common shell prompts in
addition to shell-prompt-pattern.  Maybe I should re-add this feature.

>       tramp: Looking for pattern Are you sure you want to continue connecting (yes/no)\? *
>       Quit
>
>    [Note that even though the above appears as if it's asking a user
>     question, it doesn't seem to accept any input; I have to interrupt
>     it to do anything]

Hm.  Maybe this "looking for pattern" stuff should be removed from
the default debugging messages.

>    Looking in the `*tramp/su root@localhost*' buffer, I see:
>
>
>       mcspd15:~# 
>
>    [that's a blank line at the beginning].

Looks like the same shell prompt problem.

kai
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)

Re: tramp

[Miles Bader]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
> >       tramp: Looking for pattern ^\(([^) 	]*)\|[^> 	]*[>]\)\s-*
> 
> This looks like your shell-prompt-pattern.  Is it?

Ah, perhaps it is.  Since shell-prompt-pattern is basically not used anymore,
I had forgotten that I had one.  However, in this case it's still clearly
wrong, since it's not _my_ shell that's being started, but root's.

> At this point, Tramp is again waiting for shell-prompt-pattern, and
> this shell prompt does not match the regexp above.
> 
> It used to be that Tramp tried to grok some common shell prompts in
> addition to shell-prompt-pattern.  Maybe I should re-add this feature.

I think it _definitely_ should match common shell prompts, as
`shell-prompt-pattern' is quite likely to be wrong, for the reasons I gave
above:

 (1) It's not used by shell-mode anymore, so it's going to suffer bit-rot.

 (2) In many cases, a shell started by tramp will be in a `different
     context' than a normal user-shell, and so will have a different
     prompt anyway.

Probably it ought to be possible to modify this on a per-connection-type and
per-machine basis (but presumably that will be handled by the whizzy config
mechanism that will added to address other problems, right?).

-Miles
-- 
The secret to creativity is knowing how to hide your sources.
  --Albert Einstein

Re: tramp

[Kai Großjohann]

Miles Bader <miles@lsi.nec.co.jp> writes:

> Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
>> >       tramp: Looking for pattern ^\(([^) 	]*)\|[^> 	]*[>]\)\s-*
>> 
>> This looks like your shell-prompt-pattern.  Is it?
>
> Ah, perhaps it is.  Since shell-prompt-pattern is basically not used anymore,
> I had forgotten that I had one.  However, in this case it's still clearly
> wrong, since it's not _my_ shell that's being started, but root's.

Right.

>> At this point, Tramp is again waiting for shell-prompt-pattern, and
>> this shell prompt does not match the regexp above.
>> 
>> It used to be that Tramp tried to grok some common shell prompts in
>> addition to shell-prompt-pattern.  Maybe I should re-add this feature.
>
> I think it _definitely_ should match common shell prompts, as
> `shell-prompt-pattern' is quite likely to be wrong, for the reasons I gave
> above:

Okay, Tramp now has its own variable, tramp-shell-prompt-pattern,
that users can set.  The default value is the same as the default
value for shell-prompt-pattern, so it should match the prompts that
your examples showed.

>  (1) It's not used by shell-mode anymore, so it's going to suffer bit-rot.

Ah.  Hm.  shell-mode just assumes that everything on the last line is
a prompt, right?  Hm.  But I think it's not possible for Tramp to
assume something similar.

It is vital for Tramp to wait until it sees a shell prompt before
sending something to the remote shell.  If you send input to the
remote shell too early, things go wrong in a quite horrible way
(depending on the remote login program that you are using).

But maybe waiting for the shell prompt is not the right thing to do.
What could Tramp do instead?

(After Tramp has ascertained that it is indeed talking to the remote
shell, it sets the shell prompt to a special value and then uses
that, and this mechanism works well.  I haven't heard any complaints,
yet, at least :-)

>  (2) In many cases, a shell started by tramp will be in a `different
>      context' than a normal user-shell, and so will have a different
>      prompt anyway.
>
> Probably it ought to be possible to modify this on a per-connection-type and
> per-machine basis (but presumably that will be handled by the whizzy config
> mechanism that will added to address other problems, right?).

Is it really necessary to modify the regexp like this?  Isn't it
enough for the user to set one value which covers all alternatives?

If possible, I would like to avoid having too many parameters that
are based on method or machine.

But I'm having similar arguments about tramp-remote-path.  It's also
just one variable, and people are requesting me to make it
configurable on a per-host basis.  But I think it is sufficient to
have one global value which contains all the directories on all the
hosts.

kai
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)

Re: tramp

[Miles Bader]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
> Tramp now has its own variable, tramp-shell-prompt-pattern, that users
> can set.  The default value is the same as the default value for
> shell-prompt-pattern, so it should match the prompts that your examples
> showed.

I just tried tramp /su:localhost:/etc again today, and it works!

Startup's a bit slow though; it'd be nice if all the file-downloading
&c could be omitted on a local connection (presumably that couldn't be
the default, but it could be configurable).  Actually it would be nice
to be able to say, for _any_ specific host/user/method combo `I've
already installed tools x&y, here's where you can find them.  Yet
another job for the whizzy per-method/machine/user configuration alist.
[I guess there are probably variables for this; I've not checked.]

> shell-mode just assumes that everything on the last line is a prompt,
> right?  Hm.  But I think it's not possible for Tramp to assume something
> similar.

Probably not.

> It is vital for Tramp to wait until it sees a shell prompt before
> sending something to the remote shell.  If you send input to the
> remote shell too early, things go wrong in a quite horrible way
> (depending on the remote login program that you are using).
> 
> But maybe waiting for the shell prompt is not the right thing to do.
> What could Tramp do instead?

I don't know; is simply waiting for _some_ output too optimistic?

> >  (2) In many cases, a shell started by tramp will be in a `different
> >      context' than a normal user-shell, and so will have a different
> >      prompt anyway.
> >
> > Probably it ought to be possible to modify this on a
> > per-connection-type and per-machine basis (but presumably that will be
> > handled by the whizzy config mechanism that will added to address
> > other problems, right?).
> 
> Is it really necessary to modify the regexp like this?  Isn't it
> enough for the user to set one value which covers all alternatives?

Perhaps, but I think for me, it's more natural to think in little bits,
for concrete cases, rather than trying to cover all cases with one mondo
regexp.

It's also possible that there will in fact be conflicts, though I haven't
any personal experience of any (e.g., host X uses a shell prompt that
actually matches some other non-shell prompt login output on host Y).

> If possible, I would like to avoid having too many parameters that
> are based on method or machine.
> 
> But I'm having similar arguments about tramp-remote-path.  It's also
> just one variable, and people are requesting me to make it configurable
> on a per-host basis.  But I think it is sufficient to have one global
> value which contains all the directories on all the hosts.

I think this is a much more dangerous assumption than in the prompt case,
since what is a trusted directory on one host may not be on another.

Since there definitely are parameters which will have to be host/method
specific, and that you're better off simply making a general mechanism by
which _all_ parameters can be set on a host/method specific manner.

E.g., just an alist containing machine/method/user specs, and variables
and values, which tramp will run down and do
  (set (make-local-variable VAR) val)
inside the tramp work buffer.  Then the code can use simple variables,
but the user still gets max flexibility where needed.

An example format might be:

  ((SPEC (VAR . VAL) ...) ...)

where SPEC is either a regexp matching the hostname, or a tuple like
(HOST USER METHOD) where the components are regexps or nil (meaning
match anything).

That's what I want.

[I haven't looked at tramp's code though, so perhaps the above is not a
workable solution.]

Thanks,

-Miles
-- 
Suburbia: where they tear out the trees and then name streets after them.

Re: tramp

[Kim F. Storm]

Miles Bader <miles@lsi.nec.co.jp> writes:

> Since there definitely are parameters which will have to be host/method
> specific, and that you're better off simply making a general mechanism by
> which _all_ parameters can be set on a host/method specific manner.
> 
> E.g., just an alist containing machine/method/user specs, and variables
> and values, which tramp will run down and do
>   (set (make-local-variable VAR) val)
> inside the tramp work buffer.  Then the code can use simple variables,
> but the user still gets max flexibility where needed.
> 
> An example format might be:
> 
>   ((SPEC (VAR . VAL) ...) ...)
> 
> where SPEC is either a regexp matching the hostname, or a tuple like
> (HOST USER METHOD) where the components are regexps or nil (meaning
> match anything).
> 
> That's what I want.
> 

So do I.

I have actually very few remote machines I connect to, so I would
like to be able to configure tramp for each of those with the
optimal set of parameters (and faster connect times).

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Tramp

[David Kastrup]

Bill Wohler <wohler@newt.com> writes:

> David Kastrup <dak@gnu.org> wrote:
>
>> C-x C-f /sudo::FILE RET
>> C-x C-f /ssh:SOME_REMOTE_MACHINE:FILE RET
>
> How about if I want to run "M-x svn-status RET / RET" as root
> locally.

M-x svn-status RET /sudo::/ RET

> How about if I want to run "M-x svn-status RET DIRECTORY RET" as either
> me or as root on a remote machine?

M-x svn-status RET /ssh:root@SOME_REMOTE_MACHINE:FILE RET

> Note that the remote machine is configured to not accept ssh
> connections as root--you have to log in as another user first.

> I tried "M-x svn-status RET /ssh:host:~wohler RET" and that produced
> a view of my home directory on localhost.

Then there is something wrong and you should file a proper bug report.

> Also, I read in the manual (for tramp version 2.1.11) about
> tramp-default-proxies-alist so that one can edit files as root on a
> remote host, but that variable does not appear to be available in
> tramp 2.0.55 (in Emacs 22).

You can use multihop methods.

-- 
David Kastrup

Re: Tramp

[Michael Albinus]

Bill Wohler <wohler@newt.com> writes:

> How about if I want to run "M-x svn-status RET / RET" as root locally.
>
> How about if I want to run "M-x svn-status RET DIRECTORY RET" as either
> me or as root on a remote machine? Note that the remote machine is
> configured to not accept ssh connections as root--you have to log in as
> another user first. I tried "M-x svn-status RET /ssh:host:~wohler RET"
> and that produced a view of my home directory on localhost.

All this should be possible with Tramp 2.1, which is integrated in the
Emacs trunk.

> Also, I read in the manual (for tramp version 2.1.11) about
> tramp-default-proxies-alist so that one can edit files as root on a
> remote host, but that variable does not appear to be available in tramp
> 2.0.55 (in Emacs 22).

Emacs 22.x won't be upgraded to Tramp 2.1 I suspect. So you must
either use Emacs 23.0.50 (that is the Emacs trunk from CVS), or
install Tramp 2.1 in parallel to Emacs 22.

> Thanks again.

Best regards, Michael.