[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#43003: 28.0.50; comint-password-prompt-regexp too restrictive
From: |
Stephen Berman |
Subject: |
bug#43003: 28.0.50; comint-password-prompt-regexp too restrictive |
Date: |
Sun, 23 Aug 2020 23:26:26 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
On one of my systems, when using ssh in shell-mode (M-x shell), the
password prompt does not appear in the minibuffer but only in the
*shell* buffer directly under the ssh invocation, and the password is
not hidden when it's entered. I've determined that reason is that the
password prompt string passed to comint-output-filter begins with a
carriage return character (^M), and when the rest of the prompt string
begins with "Password" (which it can on this system),
comint-password-prompt-regexp does not match it and thus
comint-watch-for-password-prompt returns nil instead of calling
comint-send-invisible.
So far I haven't found out where the carriage return is coming from,
maybe it's from openssh (on the system where the carriage return occurs
in the prompt string I have openssh-8.2p1, another system where the
carriage return does not occur has openssh-7.9p1; if anyone knows the
answer, or has a suggestion for how to find out, I'd appreciate hearing
it).
As a workaround, I can customize comint-password-prompt-regexp to match
the prompt with the carriage return. But this problem could be seen as
a datapoint in favor of changing the default value of
comint-password-prompt-regexp. Already in bug#31075 Noam Postavsky
pondered whether eshell-password-prompt-regexp should replace
comint-password-prompt-regexp, noting that "the eshell regexp looks much
simpler". And indeed, on the system where the carriage return occurs in
the prompt string, using ssh in the Emacs shell (M-x eshell) does use
the minibuffer for password input and it is hidden; and if I set
comint-password-prompt-regexp to eshell-password-prompt-regexp, then I
also get minibuffer hidden input in shell-mode.
So this bug report is basically a plea to change the default value of
comint-password-prompt-regexp to be the same as that of
eshell-password-prompt-regexp. Or is there a good reason not to do
this?
In GNU Emacs 28.0.50 (build 16, x86_64-pc-linux-gnu, GTK+ Version 3.24.17,
cairo version 1.17.3)
of 2020-08-21 built on strobe-jhalfs
Repository revision: 3e10174fb65f4eb601b1921271bdcf10c933b879
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12008000
System Description: Linux From Scratch SVN-20200401
Configured using:
'configure 'CFLAGS=-Og -g3' PKG_CONFIG_PATH=/opt/qt5/lib/pkgconfig'
Configured features:
XPM JPEG TIFF GIF PNG RSVG CAIRO SOUND DBUS GSETTINGS GLIB NOTIFY
INOTIFY ACL GNUTLS LIBXML2 FREETYPE HARFBUZZ ZLIB TOOLKIT_SCROLL_BARS
GTK3 X11 XDBE XIM MODULES THREADS LIBSYSTEMD PDUMPER LCMS2
- bug#43003: 28.0.50; comint-password-prompt-regexp too restrictive,
Stephen Berman <=
- bug#43003: 28.0.50; comint-password-prompt-regexp too restrictive, Lars Ingebrigtsen, 2020/08/24
- bug#43003: 28.0.50; comint-password-prompt-regexp too restrictive, Stephen Berman, 2020/08/26
- bug#43003: 28.0.50; comint-password-prompt-regexp too restrictive, Lars Ingebrigtsen, 2020/08/27
- bug#43003: 28.0.50; comint-password-prompt-regexp too restrictive, Stephen Berman, 2020/08/27
- bug#43003: 28.0.50; comint-password-prompt-regexp too restrictive, Lars Ingebrigtsen, 2020/08/28
- bug#43003: 28.0.50; comint-password-prompt-regexp too restrictive, Stephen Berman, 2020/08/28
- bug#43003: 28.0.50; comint-password-prompt-regexp too restrictive, Lars Ingebrigtsen, 2020/08/30
- bug#43003: 28.0.50; comint-password-prompt-regexp too restrictive, Stephen Berman, 2020/08/31
- bug#43003: 28.0.50; comint-password-prompt-regexp too restrictive, Robert Pluim, 2020/08/31
- bug#43003: 28.0.50; comint-password-prompt-regexp too restrictive, Stephen Berman, 2020/08/31