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

[Tino Calancha]

On Sat, 10 Mar 2018, Eli Zaretskii wrote:

> > From: Tino Calancha <tino.calancha@gmail.com>
> > Cc: 30190@debbugs.gnu.org,  rms@gnu.org,  npostavs@users.sourceforge.net
> > Date: Sat, 10 Mar 2018 22:17:13 +0900
> >
> > 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.
>
> What happens if you have a command (say, a shell script) that prompts
> for something that is not a password with a prompt that starts with
> text that matches the regexp -- what is the behavior then, after your
> changes?  What I see here is that the filter redirects that to the
> minibuffer, and doesn't show the text I type, unlike what happened
> before your changes.  Wouldn't that look like a bug and cause bug
> reports?
IMO, if the regexp is matched, then you must be prompt in the minibuffer.
It is the responsability of the person writing the script to chose
sensible variable names, and right prompts.  If I am prompted and I
expect I shouldn't, then what is happening is that I wrote a poor script.


> I'm also worried by the "_sometimes_" part: does it mean the behavior
> is not deterministic?  Why?
This is not crafted from me; it how it's designed in comint.el.  It must
mean that the long strings are send in chunks.  That would be a totally
independent bug report.  Actually if it's a bug or not is arguable:
don't think it is, at least until we canot fire it in a more sensical
example that the toy string:
[sudo] password for:

> > Whatever misfunction of my patch should happen in a dumb shell buffer
> > started with:
> > M-x shell
>
> Yes, but two wrongs don't make a right...
There levels of wrongs: showing a password is simply too wrong.

And 2 wrongs, sharing same code give more testers, i.e., more chances 
to detect the anomaly to finally fix it.

Anyway I already have patched my local sources and I am 
happy with that.  I don't have time to argue further, so I give up.
My team is pushing me to focus in our project.