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.
I’m not (familiar with Python).
Years ago, I wrote and maintained one of the core libraries for Ruby. That experience put me off scripting languages for any serious, persistent work for good. I use them for one-offs, and therefore, I stick to languages that are ubiquitous: bash, awk, sed. Lua isn’t everywhere. Neither is Python, or Ruby, or Perl. But bash, awk, and sed are.
Except that, in BB, they’re often stripped down so much they’re barely functional.
Look, somehow this has become about OpenWRT. That was just a latest example; my post was about BusyBox, and Lua isn’t part of BusyBox. I just want developers to consider their deployment environment and maybe generate and include more capable, POSIX BB instead of just choosing the smallest and most useless.
This is completely fair, but the only example you gave to show this was about regexp in OpenWRT, and it seems from the other comments like there are several ways to go about doing this. You mentioned half of your RAM being free, but on the flip side of that, something with half as much RAM or less would be struggling a lot more. Admittedly I don’t know much about OpenWRT but routers aren’t exactly known for being powerful systems, so to me this seems like a perfect use case for a leaner set of utilities.
To your other point, languages like Python and Lua might not technically be everywhere but it they are common enough and simple enough to learn that you really are holding yourself back by avoiding them. Lua in particular is used by a lot of Linux projects (e.g. Neovim and Awesome WM are the most recent that I’ve used but there are tons of others) because of how easy it is to embed a configuration/plugin API into existing codebases.
Tldr; you’re being dissed because the only example you gave about BusyBox being overused is (on the surface at least) a valid use case with easy solutions that you seem to be intentionally ignoring.
Yeah, fuck giving examples, because people ignore the stated problem and focus on the example. You’re exactly right. It’s stackexchange all over again, and I should know better than to provide any specifics, because people can not resist solving the wrong problem.
There’s an actual term for this behavior, but it escapes me. It’s the opposite of the X/Y problem, where people fixate on some irrelevant detail. I need to learn to ignore “can you give an example” comments, because all that leads to use someone trying to fix a specific instance of a larger, more general problem.