[Toybox] --version for all commands?

[Rob Landley]

On 09/30/2016 03:32 PM, enh wrote:
> On Fri, Sep 30, 2016 at 1:17 AM, Rob Landley <rob at landley.net> wrote:
>> Because autoconf is grepping for "GNU sed version xxx" and making sure
>> the xxx is high enough, otherwise it does really STUPID workarounds that
>> were last tested in 1991 and break stuff.
>>
>>   http://lists.busybox.net/pipermail/busybox/2004-January/044644.html
> 
> (you could maybe do the web browser thing of "i'm actually SomeBrowser
> x.y.z (but i'm similar to MS Browser you've hard-coded)"?)

Well it says "This is not" at the start, so it sort of already does. :)
Either way, matches the regex, works in autoconf.

I've ranted before about how all three build steps (configure, make,
make install) are fundamentally broken and need a cvs->git style rebase
on entirely new ideas.

http://lists.landley.net/pipermail/aboriginal-landley.net/2011-June/000859.html
http://lists.landley.net/pipermail/aboriginal-landley.net/2011-June/000860.html

Unfortunately, A) I'm not sure what those ideas should _be_ (beyond what
I ranted about in those old posts), B) Linus got the world to
standardize on git (instead of mercurial) by converting the Linux repo
to it and leveraging that.

Lots of people are switching to cmake, which I'm not convinced about and
which only solves part of the problem. Android's switching to ninja,
which seems completely undocumented and I haven't figured out how to
build it _outside_ of android...

Of course this primarily applies to C projects; stuff written in
scripting languages hasn't got a compile step. But you can't write a
scripting language _in_ a scripting language, the hardware's gotta get
machine language to run somehow.

One of the many todo item clusters I don't have time for and would
really like somebody to "steal my ideas" on. (Why are people always
worried somebody will steal your idea and do the work for you? The
problem is they WON'T and you have to do the work yourself. Sigh.)

>>> somewhat related, is there a reason we don't advertise "toybox" in the
>>> --version output?
>>
>> It didn't because --version was an argument to the toybox command?
>>
>> Does cat --version say coreutils? Huh, apparently so...
> 
> yeah, i think this is where the expectation is coming from. you and i
> think "toybox" and know that the binary that everything's a symlink to
> has options of its own, but it turns out that not all users do.

Alright, I guess I'm convinced. (The other reason was to make the
version programmatically easy to parse, but eh. Nobody can make any
sense of a git hash at the best of times.)

Oh, and it only works as argv[1], if you do "ls blah --help" it won't
show help, and "ls blah --version" won't show version. Bypassing the
normal option parsing. On the bright side, "ls -- version" does what
you'd expect. :)

>>> this came up in the context of folks trying to work out what "ps"
>>> they're talking to. i've been suggesting the idiom of "toy
>>> --some-option-you-want-that-toolbox-did-not-have || toy
>>> --legacy-option", particularly "ps -e || ps" to get the -A behavior
>>> even if you have a tty.
>>>
>>> but people find it surprising that (say) ps --version doesn't work,
>>> and i suspect that if it did work, they'd find it surprising that it
>>> doesn't say "toybox" anywhere in the output.
>>
>> If you feel strongly about it we can change it, but the existing logic
>> was that the ps executable is a symlink to toybox, and toybox has --version.
> 
> well, *i'm* fine :-)
> 
> i don't have a strong use case, but wanted to pass along "not all your
> users know the symlink thing is even a thing" and "not all your users
> know that the toybox binary itself has options" (plus, possibly, "not
> all toybox users know they're toybox users"). specifically, on a bug
> report someone mentioned that they couldn't give a version for ps
> because "ps --version" doesn't work. i suspect others will stop there
> too.

Alright, try now.

> it's only come up once so far, though, so if you want to wait and see
> i'll let you know if this keeps cropping up.
> 
> (on the "it was good enough for busybox" front:

Which is just a datapoint, not necessarily a strong argument. :)

> is there an OS where busybox is the default?

A few, the most widely used is probably Alpine Linux, which is more or
less the default OS of docker images.

> or are folks with busybox implementing their
> /bin all cognizant of the fact because they had to manually do that to
> themselves in the first place?)

Rob