GNU bug report logs - #18891
Doesn't handle pwd = /C: very well

Previous Next

Package: emacs;

Reported by: Glenn Morris <rgm <at> gnu.org>

Date: Wed, 29 Oct 2014 20:04:01 UTC

Severity: minor

Found in version 24.4

Fixed in version 24.5

Done: Michael Albinus <michael.albinus <at> gmx.de>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 18891 <at> debbugs.gnu.org
Subject: bug#18891: Doesn't handle pwd = /C: very well
Date: Tue, 04 Nov 2014 13:48:58 +0100
Glenn Morris <rgm <at> gnu.org> writes:

> On a GNU/Linux system:
>
> mkdir -p /C:
> cd /C:
> emacs-24.4 -Q
>
> ->
>
>     Tramp: Opening connection for C using scp...
>     Opening connection for C using scp... \
>     Tramp: Sending command `exec ssh    -e none C'
>     Tramp: Waiting for prompts from remote shell...
>     Waiting for prompts from remote shell... \
>     Tramp failed to connect.  If this happens repeatedly, try
>         `M-x tramp-cleanup-this-connection'
> [waits for ~ 30 seconds]
>     Wrote /home/rgm/.emacs.d/tramp
>
> and Emacs never actually starts.

1. The Lisp backtrace reads like this:

  ...
  apply(tramp-sh-file-name-handler expand-file-name ("/C:./." nil))
  tramp-file-name-handler(expand-file-name "/C:./." nil)
  file-attributes("/C:./.")
  normal-top-level()

   "/C:" as default directory is wrong. It triggers Tramp to start,
   which fails. Maybe one could prevent this problem by giving the
   default directory the prefix "/:".

2. If I wrap the call of `file-attributes' in `normal-top-level' with
   `ignore-errors', Emacs starts up after claiming the Tramp
   error. However, the docstring of `file-attributes' says "Value is nil
   if specified file cannot be opened.". Therefore, `file-attributes'
   itself must suppress errors even in such calls like

   dired.c:912:  filename = Fexpand_file_name (filename, Qnil);

3. The 30 sec delay is caused by Tramp, which tries to show the
   connection buffer in order to give the user the possibility to know
   what's up. This is not useful in this case, because Emacs hasn't
   started yet. I would like to suppress this pause at this stage;
   however I didn't find a way, how I could check whether Emacs is able
   to show a buffer to the user (startup finished). A hint for this kind
   of check would be helpful for me.

> cf: http://lists.gnu.org/archive/html/bug-gnu-emacs/2001-09/msg00154.html

13 years old ... it's time to fix it.

Best regards, Michael.




This bug report was last modified 10 years and 193 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.