[Toybox] [PATCH] Fix killall prompt.

[Rob Landley]

On 09/09/2015 08:49 PM, enh wrote:
> On Tue, Sep 8, 2015 at 3:06 PM, Rob Landley <rob at landley.net> wrote:
>> On 09/07/2015 07:32 PM, enh wrote:
>>> Fix killall prompt.
>>>
>>> I'm not sure how much we care, but the " ?" was deliberately done to
>>> match the desktop.
>>
>> *squints*
>>
>> *tilts head*
>>
>> Do we _want_ a ? in the middle of the prompt? Yes, xubuntu's version is
>> doing that, but... why?
> 
> (i suspect it's just because a question's not a question without a '?'.)

The (Y/n): is bit of a hint. :)

>> Right.
>>
>> You cared enough about this behavior to send me a patch, which means you
>> care more than I do.
> 
> oh, i don't really care at all.

Still possibly more than I do about this specific issue, but what I do
care about is drawing the line against treating a specific
implementation as a standard.

I'm happy to make the change if there's a reason, but changing behavior
_just_ because that's what the other one does is a hole with no bottom
and a precedent I'd like to avoid. I try to leave the occasional
intentional gap when I _know_ it doesn't matter just so people don't
send me a patch adding support for the $TAPE environment variable for
tar because they think they _should_ rather than because anything they
personally know of is actually using it.

In this case, the fact busybox hasn't even bothered to implement -i and
nobody's cared yet is a strong hint we can probably get away with a
little deviation here too. :)

I think in terms of 1) "behavior that's mentioned in the standard", 2)
"behavior that should be added to the standard" (would I ever
conceivably poke a standards body to specify this specific prompt?), and
3) "behavior that's accidental".

This seems accidental, and I lean towards "minimal" and "consistent" for
that.

>> (It's the aesthetic issues that are the hardest because there _is_ no
>> right answer, just different ways to be wrong.)
> 
> yeah, which is why "do what the existing tool does" seems like a
> reasonable default.

Yes, but this is adding extra code to match a behavior that makes no
sense. None of the other yesno() users has a ? before the (Y/n): prompt,
so this is inconsistent with the others, and the "Kill" vs "Signal"
difference seems completely arbitrary (and is a recent historical addition).

The question isn't "can we match", it's "should we"?

(This is far more explanation than this patch deserves, but I'm trying
to explain my reasoning. If you'd said "yes, I care strongly about this"
I'd probably go "eh" and apply the 2 line patch. Otherwise, I'd rather
leave it different.)

Rob

 1441853494.0