GNU bug report logs - #39389
27.0.60; A couple of bugs messing with minibuffer completion of /sudo::

Previous Next

Full log

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

From: Jimmy Yuen Ho Wong <wyuenho <at> gmail.com>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 39389 <at> debbugs.gnu.org
Subject: Re: bug#39389: 27.0.60; A couple of bugs messing with minibuffer
 completion of /sudo::
Date: Sun, 9 Feb 2020 23:44:01 +0000

[Message part 1 (text/plain, inline)]

Ok I've found a way to reproduce bug 2 and 3 *without* `exec-path-from-shell`.

0. Get on macOS 10.14
1. Install [GPGTools](https://gpgtools.org/), this will put the `gpg`
binary into `/usr/local/bin`
2. env -i /Applications/MacPorts/Emacs.app/Contents/MacOS/Emacs -l
tramp --eval '(setq tramp-verbose 10 exec-path (cons "/usr/local/bin/"
exec-path))' /sudo::
3. Now the minibuffer prompt will be stuck at Tramp: Sending Password.
4. C-g to quit. I've attached a backtrace and the logs in *Messages* for this.
5. The `exec-path` is now `("/usr/local/bin/" "."
"/Applications/MacPorts/Emacs.app/Contents/MacOS/libexec"
"/Applications/MacPorts/Emacs.app/Contents/MacOS/bin")`. It appears as
long as `.` is part of the search paths and `gpg` can be found in any
of the search paths, the prompt will get stuck.
6. Saving the credentials for `root <at> localhost` into `~/.authinfo.gpg`
will work around this issue.

On Sat, Feb 8, 2020 at 6:36 PM Michael Albinus <michael.albinus <at> gmx.de> wrote:
>
> Jimmy Yuen Ho Wong <wyuenho <at> gmail.com> writes:
>
> Hi,
>
> > For bug 2 and 3, the author said `file-remote-p` might have triggered
> > some weird code paths that triggered this bug. I don't know how to
> > edebug further as `redisplay_internal` keeps calling it. Do you know
> > how to debug it?
> >
> > https://github.com/purcell/exec-path-from-shell/issues/95#issuecomment-582629738
>
> I doubt that file-remote-p is guilty. This function is designed to *not*
> work on the remote side, but check the syntax of a file name only.
>
> However, I've downloaded the package exec-path-from-shell from
> MELPA. Reading the code, I have serious doubst it will cooperate with
> Tramp. It's idea is to analyze the *local* shell, and apply actions over
> the shell. But the *local* shell doesn't matter for remote files, so it
> is completely useless. I'd recommend NOT to use exec-path-from-shell for
> remote files.
>
> If you want to know mor details what happens with Tramp, you might
> analyze the function calls. Evaluate
>
> --8<---------------cut here---------------start------------->8---
> (require 'trace)
> (dolist (elt (all-completions "tramp-" obarray 'functionp))
>   (trace-function-background (intern elt)))
> (untrace-function 'tramp-read-passwd)
> --8<---------------cut here---------------end--------------->8---
>
> Then run your test. The buffer *trace-output* contains the output from
> the function call traces. You might show it here, maybe I can find
> something more about the problem.
>
> Best regards, Michael.

[without-epfs-backtrace.txt (text/plain, attachment)]

[messages.txt (text/plain, attachment)]

Previous Next

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