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

Previous Next

Full log

Message #6 received at 18891 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 18891 <at> debbugs.gnu.org
Subject: Re: 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.

Previous Next

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