[Toybox] [PATCH] Fix killall prompt.

[enh]

On Wed, Sep 9, 2015 at 7:51 PM, Rob Landley <rob at landley.net> wrote:
> 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.

...a thought which made me check BSD. they do include a "?" but in a
completely different message. so it looks like there's already plenty
of variation in the wild.

> 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



-- 
Elliott Hughes - http://who/enh - http://jessies.org/~enh/
Android native code/tools questions? Mail me/drop by/add me as a reviewer.

 1441853807.0