bug#30190: 27.0.50; term run in line mode shows user passwords

[Tino Calancha]

Eli Zaretskii <eliz@gnu.org> writes:

>> I tried just after I read your message.  I don't find a problem.
>
> Can you please show some examples?  First, what text triggers the new
> functionality correctly, when the user types a password at some
> relevant prompt, and then what happens when an unrelated prompt is
> taken by the filter function as a prompt for a password.  I'd like to
> understand better what happens in each case.
Good behaviour:
sudo ls
# you are prompted in the minibuffer for your pass

Bad behaviour:
[sudo] password for foo:
# This throws 'command not found' BUT _sometimes_ you are prompted for
# your password in the minibuffer.
# Note: This happens in a dumb shell buffer as well.

>> And as a pointed out above, it uses the same mechanism as comint.el
>> (e.g.  dumb shell buffers), so I don't think you should worry about
>> it.
>
> Sorry, this doesn't really tell me enough, because I don't think I
> understand the relevance of dumb shells and comint to the issue at
> hand.

The relevance is that:
I have copied from comint.el how to recognize a password prompt to
redirect the prompt into the minibuffer (hidding the password).

Whatever misfunction of my patch should happen in a dumb shell buffer
started with:
M-x shell

IMO such side case is not an argument to reject this patch fixing
a serious thing.

I have uploaded a video running the above examples:
https://www.dropbox.com/s/onr7peue6xd5fqh/record-desktop.mkv?dl=01
(BTW, got an offer to be the next 007 right after upload this video.
Let's see.  I am considering it...)