134466 2006-05-26 18:51 0000 portage accepts enter as yes at yes/no prompts 2009-11-04 11:23:24 0000 1 1 1 Unclassified Portage Development Core - Interface (emerge) 2.0 All Linux RESOLVED FIXED InSVN P2 minor --- 210077 288499 1 gentoo@altkai.ml1.net dev-portage@gentoo.org amne@gentoo.org askwar@digitalprojects.com betelgeuse@gentoo.org chutz@gg3.net dirtyepic@gentoo.org genstef@gentoo.org gentoo-bugs@allenjb.me.uk leio@gentoo.org nyhm@gentoo.org siryes@gmail.com zlin@gentoo.org gentoo@altkai.ml1.net 2006-05-26 18:51:23 0000 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. zmedico@gentoo.org 2006-05-26 19:12:39 0000 Thanks, this is fixed in svn r3426. siryes@gmail.com 2006-05-26 22:13:12 0000 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 :( zmedico@gentoo.org 2006-05-26 22:24:16 0000 Created an attachment (id=87615) 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. siryes@gmail.com 2006-05-27 00:45:47 0000 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)? siryes@gmail.com 2006-05-27 01:56:17 0000 Created an attachment (id=87618) 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? zmedico@gentoo.org 2006-05-27 04:25:50 0000 (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. zmedico@gentoo.org 2006-05-27 04:26:06 0000 This has been released in 2.1_rc3 mikachu@gmail.com 2006-05-27 08:13:46 0000 So it's too late in the schedule to add new features, but not too late to change default behaviour??? chutz@gg3.net 2006-05-27 08:53:53 0000 (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 antarus@gentoo.org 2006-05-27 09:18:04 0000 (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. mikachu@gmail.com 2006-05-27 09:56:23 0000 I always interpreted the green color of Yes to mean it's the default option, so I don't think it was a bug. gentoo@altkai.ml1.net 2006-05-27 10:10:52 0000 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. siryes@gmail.com 2006-05-27 10:35:08 0000 Created an attachment (id=87674) 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 carlo@gentoo.org 2006-05-27 12:21:24 0000 *** Bug 134553 has been marked as a duplicate of this bug. *** antarus@gentoo.org 2006-05-27 12:41:25 0000 (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 > siryes@gmail.com 2006-05-27 12:58:05 0000 > 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) dirk@liji-und-dirk.de 2006-05-27 17:16:39 0000 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)... dirtyepic@gentoo.org 2006-05-27 22:12:31 0000 ditto. this is amazingly annoying. please consider reverting this. leio@gentoo.org 2006-05-27 22:20:35 0000 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. askwar@digitalprojects.com 2006-05-27 22:38:57 0000 (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). zmedico@gentoo.org 2006-05-27 22:50:13 0000 (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. jstubbs@gentoo.org 2006-05-27 22:50:56 0000 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. zmedico@gentoo.org 2006-05-27 22:58:26 0000 (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... askwar@digitalprojects.com 2006-05-27 23:01:50 0000 (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. zmedico@gentoo.org 2006-05-27 23:17:41 0000 (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). zmedico@gentoo.org 2006-05-28 03:21:45 0000 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. siryes@gmail.com 2006-05-28 07:55:20 0000 I'm not a python expert, but wouldn't sys.stdin.flush() be enough? jstubbs@gentoo.org 2006-05-28 08:28:54 0000 I had similar thoughts but after some investigating of my own: http://faq.cprogramming.com/cgi-bin/smartfaq.cgi?answer=1044873249&id=1043284392 zmedico@gentoo.org 2006-05-28 16:30:31 0000 The old behavior has been restored and the documentation has been updated in svn r3437. zmedico@gentoo.org 2006-05-28 19:22:59 0000 This has been released in 2.1_rc3-r1. zlin@gentoo.org 2006-05-28 22:02:39 0000 (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.. zlin@gentoo.org 2006-05-28 22:24:30 0000 (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. gentoo@altkai.ml1.net 2006-05-28 23:57:55 0000 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. blubb@gentoo.org 2006-05-29 03:33:50 0000 (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. gentoo@altkai.ml1.net 2006-05-29 11:38:32 0000 (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. jakub@gentoo.org 2006-12-17 04:52:06 0000 *** Bug 158354 has been marked as a duplicate of this bug. *** betelgeuse@gentoo.org 2006-12-17 05:10:29 0000 (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] zmedico@gentoo.org 2009-10-24 06:57:26 0000 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. zmedico@gentoo.org 2009-10-31 04:33:13 0000 This is fixed in 2.1.7.2 and 2.2_rc47. arfrever@gentoo.org 2009-11-04 11:23:24 0000 *** Bug 291823 has been marked as a duplicate of this bug. *** 87615 2006-05-26 22:24 0000 reject empty responses when the enter key is pressed userquery_empty.patch text/plain SW5kZXg6IGJpbi9lbWVyZ2UKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gYmluL2VtZXJnZQkocmV2aXNpb24gMzQy NSkKKysrIGJpbi9lbWVyZ2UJKHJldmlzaW9uIDM0MjYpCkBAIC0xMzMsNyArMTMzLDcgQEAKIAkJ d2hpbGUgVHJ1ZToKIAkJCXJlc3BvbnNlPXJhd19pbnB1dCgiWyIrc3RyaW5nLmpvaW4oW2NvbG91 cnNbaV0ocmVzcG9uc2VzW2ldKSBmb3IgaSBpbiByYW5nZShsZW4ocmVzcG9uc2VzKSldLCIvIikr Il0gIikKIAkJCWZvciBrZXkgaW4gcmVzcG9uc2VzOgotCQkJCWlmIHJlc3BvbnNlLnVwcGVyKCk9 PWtleVs6bGVuKHJlc3BvbnNlKV0udXBwZXIoKToKKwkJCQlpZiByZXNwb25zZSBhbmQgcmVzcG9u c2UudXBwZXIoKT09a2V5WzpsZW4ocmVzcG9uc2UpXS51cHBlcigpOgogCQkJCQlyZXR1cm4ga2V5 CiAJCQlwcmludCAiU29ycnksIHJlc3BvbnNlICclcycgbm90IHVuZGVyc3Rvb2QuIiAlIHJlc3Bv bnNlLAogCWV4Y2VwdCAoRU9GRXJyb3IsIEtleWJvYXJkSW50ZXJydXB0KToK 87618 2006-05-27 01:56 0000 allow empty responses when FEATURES="defaultyes" is set userquery_empty_defaultyes.patch text/plain LS0tIC91c3IvbGliL3BvcnRhZ2UvYmluL2VtZXJnZS5vcmlnCTIwMDYtMDUtMjcgMTA6Mjc6NTYu MDAwMDAwMDAwICswMjAwCisrKyAvdXNyL2xpYi9wb3J0YWdlL2Jpbi9lbWVyZ2UJMjAwNi0wNS0y NyAxMDozMjo0OS4wMDAwMDAwMDAgKzAyMDAKQEAgLTEzMyw3ICsxMzMsNyBAQAogCQl3aGlsZSBU cnVlOgogCQkJcmVzcG9uc2U9cmF3X2lucHV0KCJbIitzdHJpbmcuam9pbihbY29sb3Vyc1tpXShy ZXNwb25zZXNbaV0pIGZvciBpIGluIHJhbmdlKGxlbihyZXNwb25zZXMpKV0sIi8iKSsiXSAiKQog CQkJZm9yIGtleSBpbiByZXNwb25zZXM6Ci0JCQkJaWYgcmVzcG9uc2UudXBwZXIoKT09a2V5Wzps ZW4ocmVzcG9uc2UpXS51cHBlcigpOgorCQkJCWlmIChyZXNwb25zZSBvciAiZGVmYXVsdHllcyIg aW4gcG9ydGFnZS5zZXR0aW5ncy5mZWF0dXJlcykgYW5kIHJlc3BvbnNlLnVwcGVyKCk9PWtleVs6 bGVuKHJlc3BvbnNlKV0udXBwZXIoKToKIAkJCQkJcmV0dXJuIGtleQogCQkJcHJpbnQgIlNvcnJ5 LCByZXNwb25zZSAnJXMnIG5vdCB1bmRlcnN0b29kLiIgJSByZXNwb25zZSwKIAlleGNlcHQgKEVP RkVycm9yLCBLZXlib2FyZEludGVycnVwdCk6Cg== 87674 2006-05-27 10:35 0000 allow empty responses with FEATURES="defaultyes" (v. 2.1_rc3) userquery_empty_defaultyes.patch text/plain LS0tIGVtZXJnZS5vcmlnCTIwMDYtMDUtMjcgMTk6MTU6MDYuMDAwMDAwMDAwICswMjAwCisrKyBl bWVyZ2UJMjAwNi0wNS0yNyAxOToxNzowNC4wMDAwMDAwMDAgKzAyMDAKQEAgLTEzMyw3ICsxMzMs NyBAQAogCQl3aGlsZSBUcnVlOgogCQkJcmVzcG9uc2U9cmF3X2lucHV0KCJbIitzdHJpbmcuam9p bihbY29sb3Vyc1tpXShyZXNwb25zZXNbaV0pIGZvciBpIGluIHJhbmdlKGxlbihyZXNwb25zZXMp KV0sIi8iKSsiXSAiKQogCQkJZm9yIGtleSBpbiByZXNwb25zZXM6Ci0JCQkJaWYgcmVzcG9uc2Ug YW5kIHJlc3BvbnNlLnVwcGVyKCk9PWtleVs6bGVuKHJlc3BvbnNlKV0udXBwZXIoKToKKwkJCQlp ZiAocmVzcG9uc2Ugb3IgImRlZmF1bHR5ZXMiIGluIHBvcnRhZ2Uuc2V0dGluZ3MuZmVhdHVyZXMp IGFuZCByZXNwb25zZS51cHBlcigpPT1rZXlbOmxlbihyZXNwb25zZSldLnVwcGVyKCk6CiAJCQkJ CXJldHVybiBrZXkKIAkJCXByaW50ICJTb3JyeSwgcmVzcG9uc2UgJyVzJyBub3QgdW5kZXJzdG9v ZC4iICUgcmVzcG9uc2UsCiAJZXhjZXB0IChFT0ZFcnJvciwgS2V5Ym9hcmRJbnRlcnJ1cHQpOgo=