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 attachment 87615 [details, diff] 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 attachment 87618 [details, diff] 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 attachment 87674 [details, diff] allow empty responses with 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]
In svn r14710 I've added a --ask-enter-invalid option. When used together with the --ask option, a single "Enter" key press is interpreted as invalid input.
This is fixed in 2.1.7.2 and 2.2_rc47.
*** Bug 291823 has been marked as a duplicate of this bug. ***
*** Bug 500738 has been marked as a duplicate of this bug. ***
