This is kind of a rant, but mostly a plea.
There are times when BusyBox is the only tool you can use. You've got some embedded device with 32k RAM or something; I get it. It's the right tool. But please, please, In begging you: don't use it just because you're lazy.
I find BusyBox used in places where it's not necessary. There's enough RAM, there's more than enough storage, and yet, it's got BusyBox.
BusyBox tooling is absolutely aenemic. Simple things, common things, like - oh, - capturing a regexp group from a simple match are practically impossible. But you can do this in bash; heck, it's built in! But BusyBox uses ash, which is barely a shell and certainly doesn't support regexp matching with group capture. Maybe awk? Well, gawk lets you, with -oP, but of course BusyBox doesn't use GNU awk, and so you can't get at the capture groups because it doesn't support perl REs. It'd be shocking if BusyBox provided any truly capable tools like ripgrep, in which this would be trivial. I haven't tried BB's sed yet, because sed's RE escaping is and has always been a bizarre nightmarish Frankenstein syntax, but I've got a dime riding on some restriction in BB's sed that prevents getting at capture groups there, too.
BusyBox serves a purpose; it is intentionally barely functional; size constraining trumps all other considerations. It achieves this well. My issue isn't with BusyBox, it's with people using it everywhere when they don't need to, making life hell for anyone who's trying to actually get any work done in it.
So please. For the sanity of your users: don't reach for BusyBox just because it's easy, or because you're tickled that you're going to save a megabyte or two; please spare a thought for your users on which you are inflicting these constraints. Use it when you have to, because otherwise it doesn't fit. Otherwise, chose a real shell, at least bash, and include some tools capable of more than less than the bare minimum.
No offense taken.
If I were a professional programmer, I'd be doing this. I was a professional software engineer for 20 years before I took a management role, then managed software teams, and then organizations, for another decade before I chose to do something else. One of the things I decided was that I wasn't going to work on, or with, technology I didn't like anymore - as long as I had any choice, and since all my software development is voluntary pet projects, I'm able to do this. It has, in the aggregate, greatly improved my mental well-being to not have to work with crap anymore. I mostly avoided having to touch Windows in decades; I had only a brief brush with JavaScript that left only minor scarring, and with WASM there's every hope I can even do web-based projects should I get the itch without killing brain cells with JS. Having spent years with C++ and decades programming Java, I'm convinced that I've learned enough about what's horrible in software, and don't really need to spend more time being taught about new ways developers can screw up the software engineering space. SOAP alone covered most of the bases of bad design and architecture.
So now, I get to select where I play. I can focus on learning new things that I think are good, rather than being forced to figure out ways to work around the bad.
My original plea was simply: if you can use defacto standards, please do.
Insofar as the technology limits me in what's available, absolutely. Mainly, though, I choose to focus on supporting projects and products that support standards. If a project wants to be a Special Flower and use BrainFuck as it's tooling language, good for them! But I'm going to look for alternatives.
I would prefer, however, that projects - when they're using software that could be more standards compliant by using a few more MB, and have the space to do so, simply be compliant and ship something less stripped down.
To be precise, I'm focused on the fact that, in a toolset where usually at least one of many standard tools provides a functionality, none do. I'm not complaining that ash doesn't support regexp string matching with groups; in complaining that BB was compiled such that none of the standard tools do.
Yes. I tried 3 or 4 of the standard, usual ways to break out and parse data. My next attempt was going to resort to field cutting, hoping that that also hadn't been stripped out.
Eventually, I hacked a solution together in Lua, which will be useless the next time I encounter a stripped down BB that isn't in OpenWRT, and I'll have to waste time trying to work around broken tooling again.