bug#71576: 30.0.50; [PATCH] Improve performance of Comint/Eshell password prompt handling

[Michael Albinus]

Jim Porter <jporterbugs@gmail.com> writes:

Hi Jim,

> How long can a password prompt really be? In Comint and Eshell, we
> check for output from subprocesses that looks like a password prompt,
> so that we can hide the password when the user types it in. That's
> good, but for commands that output a lot of text, it can take a while
> to scan through it all.
>
> The attached patch adds a performance optimization for this: since we
> only check for password prompts at the end of a block of output (the
> subprocess is presumably waiting for the user to type in their
> password), we only need to look at the last N characters, where N is
> whatever the maximum password prompt length is. There's obviously no
> *strict* maximum here, but I can't imagine a password prompt being
> longer than 256 characters. Compared to the default
> 'read-process-output-max' value of 4096, this means we could skip up
> to 93% of the output when looking for the prompt.

FTR, Tramp scans output for a prompt from the end for years. It's not
only a password prompt, but also a shell prompt it looks for. It
restricts itself to 256 characters.

--8<---------------cut here---------------start------------->8---
(defun tramp-search-regexp (regexp)
  "Search for REGEXP backwards, starting at point-max.
If found, set point to the end of the occurrence found, and return point.
Otherwise, return nil."
  (goto-char (point-max))
  ;; We restrict ourselves to the last 256 characters.  There were
  ;; reports of a shell command "git ls-files -zco --exclude-standard"
  ;; with 85k files involved, which has blocked Tramp forever.
  (search-backward-regexp regexp (max (point-min) (- (point) 256)) 'noerror))
--8<---------------cut here---------------end--------------->8---

Best regards, Michael.