[pacman-dev] noconfirm trivial bug - prompt printed but unused/unnecessary

[Brendan Hide]

Xavier wrote:
> But we have this generic question function.
> We could skip any printing there in case of --noconfirm, but then we
> would need to check that all the questions pacman can ask can be
> silenced.
Using --noconfirm implies a non-interactive session - which is how I 
noticed this. If a user wants to make use of --noconfirm then they must 
deal with the consequences if the default value isn't to their liking. 
There is already no way for the user to give a confirmation/rejection if 
noconfirm is set which is the correct behaviour. From my understanding, 
most defaults are safe defaults anyway.

question() has a default return value as a parameter, "short preset", 
and thus *always* has a default. Its also only ever called by yesno() - 
[Y/n], or noyes() - [y/N], both which are called appropriately 
throughout pacman. If there is a case which shouldn't have a default 
then the function is yet to be defined to handle that case.

After a lot of grepping I believe that in every case where a question is 
currently displayed, there is subsequent output indicating what action 
then takes place. As per Allan's suggestion, I'm now more in favour of 
not printing the question at all. If we don't go that route then I'd 
still prefer adding the "... defaulting to ..." text rather than doing 
nothing.

I have diffs from git ready for both cases - which shall I submit? Both? 
Do I just mail it here?

-- 
__________
Brendan Hide