xbps-install: Pressing Enter at confirmation prompt should ignore or require explicit input (prevent accidental proceed)

[RandallFlagg]

Description

When running xbps-install (e.g., sudo xbps-install -Su <pkgname>), XBPS prompts the user for confirmation before executing the transaction.

Currently, if the user hits Enter without typing an answer, XBPS treats it as a default affirmative and proceeds with the installation.

Proposed Change

Modify the prompt handling so that pressing Enter does not automatically proceed. Instead, pressing Enter should either be ignored (looping or requiring an explicit y/n response) or completely remove the automatic fallback to "yes" so that accidental keypresses don't initiate package transactions.

[classabbyamp]

this is an intentional design decision, following the common convention where the default is captalized ([Y/n])

[RandallFlagg]

Understood but if the convention is [Y/n] and hitting Enter triggers the uppercase default, then for a safe fallback where hitting Enter does not execute the action, shouldn't the capitalized letter be N (i.e. [y/N])?

[Vaelatern]

Yes, if the default were to say no, then it's [y/N]. Looping forever would be [y/n]. That would be the convention.

[RandallFlagg]

I will ask it differntly, why the default is Y? There are times this can be a destructive operation. if you want to say yes so much, pass the y flag. Feels like a bad practice and would be happy to change the default behaviour or at least understand what was te logic that maybe I am missing.

[Duncaen]

Its been like this for over ten years, I don't think its going to change.

I don't think xbps is an outlier here, the only programs I can think of where yes is not the default are things like cfdisk and other highly destructive actions.

apk-tools% rg -i -e 'y/n' -e 'n/y'
src/commit.c
462:                    printf("Do you want to continue [Y/n]? ");

pacman% rg yesno
./src/pacman/sync.c
143:    if(!yesno(_("Do you want to remove unused repositories?"))) {
190:                    if(!yesno(_("Do you want to remove all other packages from cache?"))) {
838:            confirm = yesno(_("Proceed with download?"));
840:            confirm = yesno(_("Proceed with installation?"));

./src/pacman/callback.c
446:                                    q->install = yesno(_("%s is in IgnorePkg/IgnoreGroup. Install anyway?"),
456:                            q->replace = yesno(_("Replace %s with %s/%s?"),
532:                            q->remove = yesno(_("File %s is corrupted (%s).\n"
543:                                    q->import = yesno(_("Import PGP key %s?"),
546:                                    q->import = yesno(_("Import PGP key %s, \"%s\"?"),

./src/pacman/remove.c
163:    if(yesno(_("Do you want to remove these packages?")) == 0) {

pacman% rg noyes
src/pacman/callback.c
468:                                    q->remove = noyes(_("%s-%s%s%s and %s-%s%s%s are in conflict. Remove %s?"),
479:                                    q->remove = noyes(_("%s-%s%s%s and %s-%s%s%s are in conflict (%s). Remove %s?"),
509:                            q->skip = noyes(_n(

src/pacman/remove.c
143:    if(holdpkg && (noyes(_("HoldPkg was found in target list. Do you want to continue?")) == 0)) {

src/pacman/sync.c
196:                    if(!noyes(_("Do you want to remove ALL files from cache?"))) {

[Vaelatern]

The presence of the prompt is enough. We don't prompt unnecessarily and there is a default-yes flag for when you don't want to review at all. I would like the default behaviour to remain [Y/n].

[Maseru898]

I don't think xbps is an outlier here, the only programs I can think of where yes is not the default are things like cfdisk and other highly destructive actions.

FreeBSD's pkg uses No as a default while emacs forces you to explicitly type yes or no. So its not unheard of, its just not as common as most people prefer convenience over security.

In FreeBSD, you have the choice however. N is the default out of the box but you can set a variable in pkg.conf to make Y the default. Having the choice usually is a good idea imho