On 09/30/2016 03:32 PM, enh wrote: > On Fri, Sep 30, 2016 at 1:17 AM, Rob Landley <r...@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 _______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net