[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: problem getting files under SunOS (from cygwin)

From: Michael Albinus
Subject: Re: problem getting files under SunOS (from cygwin)
Date: Mon, 11 Feb 2013 16:41:45 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

peng wu <address@hidden> writes:


> From emacs under cygwin, remote OS being SunOS, problem opening files,
> several issues:
> 1. need time out longer than 60 seconds. this slowness may be related
> to cygwin or the particular network situation. Also wish tramp can ask
> the password immediately instead of waiting until the remote system
> responded with a request, because I often end up coming back to
> provide the password too late and have to do it again. another wish is
> an option not to lock up the emacs completely while waiting the remote
> system to respond.

We could make this timeout customizable. However, if the connection
needs more than 60 seconds to be established, I believe the connection
is too slow to work reasonable. What are your experiences?

The password is only asked when really needed. There are a lot of
situations no password is requested, because there is a running
ssh-agent, or the user has configured auth-sources appropriately. A
request for a password would be confusing in such situations.

I recommend that you configure Tramp such a way that no interactive
password is needed. See (info "(tramp)Password handling")

> 2. Before getting to the Terminal Type prompt, we have a "RETURN to
> continue" prompt that requires the user to hit the enter key.
> In addition to adding a customer hook to detect the prompt and send
> the enter key, the tramp-send-string prove to be tricky because it
> would send nothing if "/n" is the string to be sent. My work around is
> to send a space which is turned in to a space and a return key by
> tramp-send-string, and luckily the extra space does not hurt in this
> case. tramp-send-stirng probably should send the "/n" if that is the
> thing to be sent.

There are good reasons that `tramp-send-string' does not send a single
"\n". This function is the working horse of Tramp, and often it is not
desirable to send a single newline. Your approach with sending a space
as marker sounds OK to me. Unless it doesn't work for you, I would like
to keep the behaviour as it is.

> A wish related to this is to have "just respond with
> a enter" prompts and action pre-defined, and the user only need to
> customize the prompt regexps. Another wish might be presenting the
> user where things are stopped and send the user reresponse to the
> remote system.

Having an interactive function for login prompts is a nice idea. You
could write it yourself, like this example:

--8<---------------cut here---------------start------------->8---
(defconst my-tramp-prompt-regexp
  (concat "\\(" (regexp-quote "Enter the $DISPLAY you want to use:") "\\)\\s-*")
  "Regular expression matching a login prompt question.")

(defun my-tramp-action (proc vec)
  "Enter a correct value for $DISPLAY in order to give a correct answer."
    (with-current-buffer (tramp-get-connection-buffer vec)
      (let ((enable-recursive-minibuffers t))
      (tramp-check-for-regexp proc my-tramp-prompt-regexp)
      (tramp-message vec 6 "\n%s" (buffer-string))
       vec (completing-read
             (match-string 1) '("localhost1" "localhost2" "remotehost3")))))))

(add-to-list 'tramp-actions-before-shell
             '(my-tramp-prompt-regexp my-tramp-action))
--8<---------------cut here---------------end--------------->8---

> 3. keeps getting error saying no response from "test -e /", and my
> work around is to override a defun from tramp-sh:
> ;; overriding the following from tramp-sh, tramp 2.2.3-24.1:
> ;; add catching error thrown by tramp-send-command-and-check:
> ;; wrapping the calls in condition case. Could be fixed by adding
> ;; an option to tramp-send-command-and-check as to what to return on error.

This is fixed already in Tramp 2.2.6. You could download this version,
or wait for Emacs 24.3 which carries it.

Best regards, Michael.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]