Bugzilla Bug 134466

I'm using Portage 2.0.54-r2. Press enter at any yes/no prompt (via -a), results
in Portage assuming 'yes'.

If this is intended behaviour, please consider this a request to not accept
enter at said prompt.

Thanks, this is fixed in svn r3426.

Hmm.

Is it possible to revert back to the old behaviour by setting some variable in
/etc/make.conf? During my ~3 years of using Gentoo I got used to this
feature...

So I don't really like this [forced, IMO] change :(

Created an attachment (id=87615) [edit]
reject empty responses when the enter key is pressed

(In reply to comment #2)
> Is it possible to revert back to the old behaviour by setting some variable in
> /etc/make.conf?

Not currently.  You can reverse the patch if you like.

Thanks a lot :)
Especially for a quick response!

If I have time maybe I'll hack some mechanism controlling that behaviour
by a variable from /etc/make.conf (FEATURES="defaultyes" possibly)?

Created an attachment (id=87618) [edit]
allow empty responses when FEATURES="defaultyes" is set

I got it. Here's a patch against portage-2.1_rc2-r3 that accepts enter key
if "defaultyes" is present in portage.settings.features

Is it possible/desirable to apply such a patch against official emerge?

(In reply to comment #5)
> Is it possible/desirable to apply such a patch against official emerge?

In order to meet our release schedule, we're not adding any new features to the
2.1 branch.  As for your patch, I think it would be nice if it allowed either
yes or no to be specified as the default.  Also, the prompt should indicate
what the default value is.

This has been released in 2.1_rc3

So it's too late in the schedule to add new features, but not too late to
change default behaviour???

(In reply to comment #8)
> So it's too late in the schedule to add new features, but not too late to
> change default behaviour???

+1

(In reply to comment #8)
> So it's too late in the schedule to add new features, but not too late to
> change default behaviour???
> 

A release canidate means we fix bugs.  I'd wager that this was in fact a bug,
thus it gets fixed.  We may change it later; there is talk of adding more
features to do this ( although I'm not in favor of that ) that give you the
flexability you are looking for.

I always interpreted the green color of Yes to mean it's the default option, so
I don't think it was a bug.

Agree completely with Comment #6 - that the user should be told what the
default is if enter is to be accepted as a response.

Mikael, Georgi: I truly thought this was a bug that did not appear in past
Portage versions. While I sympathize, accepting enter as yes for potentially
destructive operations is not good design.

My motivation for posting was an accidental return press when switching xterms
too quickly. Fortunately, I was updating and not pruning or depcleaning at the
time.

Created an attachment (id=87674) [edit]
allow empty responses when FEATURES="defaultyes" (v. 2.1_rc3)

Patch against portage-2.1_rc3. Even though not completely useful in the long
run (impossible to select a default "yes" or "no", doesn't inform the user
which answer is the default one), I think it's worth posting anyway.

(In reply to comment #5)
> I think it would be nice if it allowed either yes or no to be specified as
> the default.  Also, the prompt should indicate what the default value is.

While I think that the prompt could indicate default value more clearly, the
possibility for "No" as the default is completely useless. One has to invoke
emerge with "-a" parameter to make it ask for confirmation. Without "-a" it
just goes and does its job without asking at all!

With "-a" defaulting to "No" one only has a double protection: first emerge
asks if it's okay to proceed, then one HAS TO type "Yes" (or a substring of
this word) to actually continue. To be asked one has to do more work already
(add the "-a" parameter), so what is the point for this double protection?

My final statement:
Do what you want with it, I know where to fix things for myself ;-)

EOT

*** Bug 134553 has been marked as a duplicate of this bug. ***

(In reply to comment #13)
> Created an attachment (id=87674) [edit]
> allow empty responses when FEATURES="defaultyes" (v. 2.1_rc3)
> 
> Patch against portage-2.1_rc3. Even though not completely useful in the long
> run (impossible to select a default "yes" or "no", doesn't inform the user
> which answer is the default one), I think it's worth posting anyway.
> 
> (In reply to comment #5)
> > I think it would be nice if it allowed either yes or no to be specified as
> > the default.  Also, the prompt should indicate what the default value is.
> 
> While I think that the prompt could indicate default value more clearly, the
> possibility for "No" as the default is completely useless. One has to invoke
> emerge with "-a" parameter to make it ask for confirmation. Without "-a" it
> just goes and does its job without asking at all!
Most people I talk to have -a in EMERGE_DEFAULT_OPTS and thus it's always on.

> 
> With "-a" defaulting to "No" one only has a double protection: first emerge
> asks if it's okay to proceed, then one HAS TO type "Yes" (or a substring of
> this word) to actually continue. To be asked one has to do more work already
> (add the "-a" parameter), so what is the point for this double protection?
> 
> My final statement:
> Do what you want with it, I know where to fix things for myself ;-)
> 
> EOT
> 

> Most people I talk to have -a in EMERGE_DEFAULT_OPTS and thus it's always on.

Most users I know never heard of this variable. It's not mentioned in Handbook
(http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?full=1) and only
advertized in "emerge --info" output:

Unset:  CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, PORTAGE_RSYNC_EXTRA_OPTS

Now that you've mentioned that, EMERGE_DEFAULT_OPTS is empty by default and
people putting "-a" there already knew what were they doing, right? So, for
a long time nobody complained, and now the current stable behaviour is
considered a bug. How nice.

(sorry, but you made me write this)

sorry that i have to give my comment, i use ~arch portage since it appeared and
as long as i remember whenever i pressed enter the action just started
it actually is really annoying now that the empty response is not understood
anymore and i explicit have to type y to get emerge started
no as standard response is even more 'strange' then i can rid -a completely and
just use -p since i won't start emerge then anyway

i'd be happy to see that useful yes for empty respose back in portage

actually till now i always took the green answer as the default, never occured
otherwise to me


...just a frequent emerge users comment (with -a in emerge default options)...

ditto.  this is amazingly annoying.  please consider reverting this.

Same here. It's simply bothering to have to write Y instead of just enter.
The main purpose of emerge -a (which I have in default opts) to me (and
probably many others) is to see what will be done prior to doing it, and
usually just ACK it. Therefore, I just emerge world, quickly see what's going
to be done, and just hit enter.
Furthermore, with -a in default opts, it will ask for confirmation on things
like emerge --sync as well. I used to just type emerge --sync and hit enter
twice to get past the question. Now I can't.
I don't see the reasoning of this change - Yes was brought out as green, e.g
the default, and now it doesn't work in the middle of release candidates.

(In reply to comment #18)
> ditto.  this is amazingly annoying.  please consider reverting this.
> 

Same here. I also don't agree that it is dangerous to accept <Enter> as <y>, as
the user has to explicitly ask for being asked - either by calling "emerge -a"
or putting "-a" in the default opts.

Further, I always understood the green Yes to mean, that this is the default.
So, for me, it was NO bug that <Enter> acted as if the default were entered.

Please revert this or apply the patch. I mean, it cannot be too late in the
schedule for such a patch, as it was not too late in the schedule to introduce
a new feature (<Enter> does not mean <y> - this is a new feature and no bug
fix).

(In reply to comment #20)
> (<Enter> does not mean <y> - this is a new feature and no bug fix).

I say it's bug.  For example, if there user types `emerge -a depclean` and hits
the enter key twice instead of once, the prompt no longer works as expected and
can lead to bad consequences.

The middle ground of clearing the input buffer before displaying the text
sounds like the best road here. The only reason for not having <enter> default
to <yes> is accidentally hitting enter twice when executing emerge. If the
input buffer is cleared, that issue is resolved.

(In reply to comment #12)
> My motivation for posting was an accidental return press when switching xterms
> too quickly. Fortunately, I was updating and not pruning or depcleaning at the
> time.

This is not really good reasoning. Accidents of this nature are just as likely
to happen regardless of what needs to be entered. For example, you type "y",
then realize that you don't want to do whatever is suggested, go to hit
backspace but hit enter instead.

(In reply to comment #22)
> The middle ground of clearing the input buffer before displaying the text
> sounds like the best road here. The only reason for not having <enter> default
> to <yes> is accidentally hitting enter twice when executing emerge. If the
> input buffer is cleared, that issue is resolved.

I like that idea.  I'll go ahead and do that for rc3-r1...

(In reply to comment #21)
> (In reply to comment #20)
> > (<Enter> does not mean <y> - this is a new feature and no bug fix).
> 
> I say it's bug.  For example, if there user types `emerge -a depclean` and hits
> the enter key twice instead of once, the prompt no longer works as expected and
> can lead to bad consequences.

But the user would have first to enter "emerge -a", which is not a default
(adding it to the default opts in make.conf doesn't count).

But what happens, if the user accidentally hits "y<enter>"? The prompt then
also doesn't as expected.

(In reply to comment #24)
> But what happens, if the user accidentally hits "y<enter>"? The prompt then
> also doesn't as expected.

That is much less likely to occur that the "pressing enter twice" scenario. 
Anyway, "yes" will be the default once again in rc3-r1 (though the input buffer
will be cleared and the prompt will clearly indicate that "yes" is the default
response).

After doing some investigation, it seems that there's no really clean way to
flush  the buffer for stdin.  It would take more than a couple lines of code
and would basically would amount to adding a new feature. So... I guess we'll
have to just revert to the old behavior but document it so that it doesn't
catch anyone by surprise.

I'm not a python expert, but wouldn't

  sys.stdin.flush()

be enough?

I had similar thoughts but after some investigating of my own:

http://faq.cprogramming.com/cgi-bin/smartfaq.cgi?answer=1044873249&id=1043284392

The old behavior has been restored and the documentation has been updated in
svn r3437. 

This has been released in 2.1_rc3-r1.

(In reply to comment #29)
> The old behavior has been restored and the documentation has been updated in
> svn r3437. 

Thank you. Remember folks, if someone by accident hits enter without meaning it
Ctrl-c does work.. This was no bug. It was clearly marked with capital Y (not
the color) and it does seem completely logical that enter means confirm and
Ctrl-c means abort..

(In reply to comment #31)
> This was no bug. It was clearly marked with capital Y (not
> the color)[...]

Apparently this is false as the no option had a capital N too. I probably
should have checked that before posting #31, so sorry for that. IMHO Yes being
the default should be the only option beginning with a capital letter. But that
is a minor issue.

I'm frankly surprised that
a) so many people relied on enter
b) interpreted a green Yes to mean it as the option that would be selected if
they pressed enter

If I were interested in furthering this discussion, which I'm not, I would ask
you (those who see the enter-as-yes behaviour as logical) what other programs
you use that behave the same. In my experience, if a prompt presents you two
options, those are indeed the only two options. What I *have* seen is something
like "Do this? Yes/No [Yes]", which obviously indicates that one should expect
Yes to be answered if one presses enter.

With regard to this comment:
> This is not really good reasoning. Accidents of this nature are just as likely
> to happen regardless of what needs to be entered. For example, you type "y",
> then realize that you don't want to do whatever is suggested, go to hit
> backspace but hit enter instead.

I cannot agree. Two keypresses (i.e. y and enter) are much safer than one (i.e.
enter).

Again, I'm not arguing against the decision the devs made to keep the prompt as
is. Many people are accustomed to the current behaviour, and don't want it to
change for that reason. What disturbs me is how some seem to defend it as a
logical, understandable design, which it is not.

(In reply to comment #33)
> If I were interested in furthering this discussion, which I'm not, I would ask
> you (those who see the enter-as-yes behaviour as logical) what other programs
> you use that behave the same. In my experience, if a prompt presents you two
> options, those are indeed the only two options. What I *have* seen is something
> like "Do this? Yes/No [Yes]", which obviously indicates that one should expect
> Yes to be answered if one presses enter.

Think of any GUI app: When you hit enter, it's usually [OK] or whatever the
default is that is chosen.

> With regard to this comment:
> > This is not really good reasoning. Accidents of this nature are just as likely
> > to happen regardless of what needs to be entered. For example, you type "y",
> > then realize that you don't want to do whatever is suggested, go to hit
> > backspace but hit enter instead.
> 
> I cannot agree. Two keypresses (i.e. y and enter) are much safer than one (i.e.
> enter).

Sure, but it's not that hard to interrupt emerge once the enter button was
accidentally pressed twice. Also, it's not emerge's fault if the user isn't
careful enough. What's next? Spelling correction in ACCEPT_KEYWORDS? A 'Are you
sure you want to exit?' prompt? It's just as easy to accidentally ctrl-c in the
wrong terminal as pressing enter. Instead of catching all these cases, we
should simply assume that the user is clever enough.

> Again, I'm not arguing against the decision the devs made to keep the prompt as
> is. Many people are accustomed to the current behaviour, and don't want it to
> change for that reason. What disturbs me is how some seem to defend it as a
> logical, understandable design, which it is not.

Well, obviously people disagree here. I don't try to 'defend' it as logical, i
do find it logical. Reasons were already mentioned, because it is simply a
reasonable default.

(In reply to comment #34)
> Think of any GUI app: When you hit enter, it's usually [OK] or whatever the
> default is that is chosen.

For a yes/no decision, a GUI program would indicate the default via a thin
dotted box. The Portage prompt lacks an analogous indication, unless you see
green as such an indication. Additionally, programs do not generally default to
the destructive action, which Portage does.

> Sure, but it's not that hard to interrupt emerge once the enter button was
> accidentally pressed twice. Also, it's not emerge's fault if the user isn't
> careful enough. What's next? Spelling correction in ACCEPT_KEYWORDS? A 'Are you
> sure you want to exit?' prompt? It's just as easy to accidentally ctrl-c in the
> wrong terminal as pressing enter. Instead of catching all these cases, we
> should simply assume that the user is clever enough.

I'm not advocating for additional protections, and I agree that there is a
limit to how much you can protect users from carelessness. For destructive
actions, two keypresses is the ideal, and standard amount of safety.

*** Bug 158354 has been marked as a duplicate of this bug. ***

(In reply to comment #36)
> *** Bug 158354 has been marked as a duplicate of this bug. ***
> 

Could we at least change the text to something like:
Would you like to unmerge these packages? [Type No to abort]