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.
There are certainly places where BusyBox makes a lot of sense. Could you give some examples of where you’re seeing it out of place?
I preface this with a statement that I’m brand-loyal to gliNet products. Love them to bits. I love that they’re based on OpenWRT, and that you can ssh into them. But their user space tooling stinks.
They have 500MB RAM. My home router has a current uptime of 24 days, and half the RAM is still free. It’s hard to tell how much persistent storage is on the device, but there’s at least 50MB free. They could have put something a little more capable on it. It’s what I’m currently fighting with - I want to script it so my VPN exit node auto switches at random times to random nodes - and it’s just frustrating with the onboard tooling.
This isn’t the first time I’ve run into it; it’s not frequent, but it’s happened more than once, and I think it’s just a sloppy, lazy decision someone made.
If it’s OpenWrt then use Lua. You probably could have written a solution in the time it took you to come whine about BusyBox.
“Hey! The solution is to learn a new programming language, instead of using POSIX tools that have been around for literal decades.”
Great advice, buddy.
Lua is as easy as python, potentially easier. I don’t think writing a one-off script with it to solve a specific problem is a nuts idea.
Lua is 31 years old and has been included in OpenWrt by default for 15 years.
New to me.
I don’t care if it’s easy; suggesting Lua as solution is dissembling. I complained about poor tooling that doesn’t follow defacto standards when the device it’s running on could easily handle having a more common, older, standard bash than choosing some castrated shell.
If it were a forced choice, because of hardware limitations, of having Lua or bash, I could get it. Lua is more capable. But in this case, it’s not a choice of either/or; the device could easily handle both.
BusyBox is, as I understand, configurable for how “complete” it is. That’s why I say it’s lazy to pick some default minimal compile when it could be more accessible, and less of a pain in the ass for users.
Dude I mean in this in the most genuine, kind way: a significant aspect of being a successful programmer is using the tools in your environment. If you can’t do something without bringing in your Tool of Choice you’re artificially limiting yourself.
If your environment does not have a specific tool or functionality that you would prefer, you work around it. OpenWrt is an immensely capable OS and it manages to perform complex network operations within its (admittedly) constrained environment.
In this case you’re myopically focused on not even a specific language, but the language agnostic feature of regex capture groups. You should be asking yourself if there’s any other way to accomplish your goal without this (spoiler: there are probably dozens of alternatives)
Dude I mean in this in the most genuine, kind way
No offense taken.
a significant aspect of being a successful programmer is using the tools in your environment.
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.
If you can’t do something without bringing in your Tool of Choice you’re artificially limiting yourself.
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.
In this case you’re myopically focused on not even a specific language, but the language agnostic feature of regex capture groups.
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.
You should be asking yourself if there’s any other way to accomplish your goal without this (spoiler: there are probably dozens of alternatives)
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.
To be fair learning lua isn’t exactly a hard process, there’s a reason it’s embedded into so many other tools. If you’re familiar with python you’re like 85% of the way to writing something basic anyway.
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.
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.
I know this might trigger you, but… Alpine Linux
You know, I’ve never had a problem with Alpine. Maybe it’s that I’m choosing less minimal base images, but the tooling always seems sufficient, and adding extra packages is super easy. Or, maybe Alpine just builds a BusyBox with all the features turned on.
I’m pretty sure when I’ve logged into my Alpine based containers, I get Bash and not Ash. That solves, like, 70% of the problems right there. grep doesn’t need to have good regexp support, because bash has it built-in.
Alpine comes with busybox. Yes, I’m pretty sure they turn on all the good features.
By the way, on which system you were using that not all the features are turned on?
A commercial product built on OpenWRT. I love the product I’m just frustrated they aren’t using the resources available in the hardware.
I got OpenWRT on my home router and I’ve never had this issue. I guess I just never have that advanced of a use case for its command line.
You’re also free to install bash (or other sh) if space allows.
Yeah, I need to figure that part out. I’m getting familiar with uci at the moment, but I need to dig into what package management is available. There’s enough space to install bash -plenty if ash wasn’t there - but probably not enough to compile bash on the device.
Anyway, my original post wasn’t about OpenWRT. I’ll get what I need to do done, one way it another. It’s just that I keep (rarely, but mor than once) encountering these ultra-pared down BusyBoxen in places where it’s not necessary to have ultra-minimalism.
Several people have responded already as if I’m complaining about OpenWRT; one even suggested I “learn Lua, dummy,” because Lua is available in OpenWRT.
I’m not complaining about OpenWRT. I’m asking developers to think twice about micro-BB builds in their products. Does it really need to be that small?
Yeah I hear you. While I personally never fell like it’s that severe of functional limitations, I am aware on how stripped down busybox is. I’m also aware that some systems lives off 4MiB of flash and 32MiB of memory, so if you ask that question, you might get the answer “yes, it is necessary”.
Meanwhile, if you have the luxury to install bash (or other full-featured shell), then that’s one option to consider. You seem lime you’re familiar with UNIX shell, and Lua is a whole new language. The Lua interpreter that comes by default might be stripped down as well anyway.
I agree, there are places where a totally stripped down BB makes sense; I’m not arguing that. I’m arguing against stripped down BB when it isn’t necessary.
Also: Lua is 1.536MB on my system. Bash is 1.1MB. I don’t know how big ash is, because I didn’t easily find the sources for it, but even if it were half the size of bash, replacing ash with bash would make the cost of adding bash only 0.6MB - a third of including Lua. If you think you have enough space for Lua, you probably have enough space for bash instead of ash.
And you be able to do normal scripting with proper regexp support and not forcing your users to learn another language just to hack together a small solution.
I want to thank you for a calm, reasoned, sympathetic discussion about something that’s currently, actively irritating me and making my responses more… acidic… than they should be.
anaemic* (Sorry, that bothered me for some reason.)
As for capture groups, you’ll have to find another way. Perversely, perhaps BusyBox continues to be included on certain systems because they know that the extra space is required for the code that works around BB’s shortcomings. That sounds asinine until you realise that “solving the problem properly” most likely leads to that one XKCD comic about the proliferation of competing standards.
At worst, multiple sizes of BusyBox itself.
No worries on the spelling correction. I don’t know why autocorrect let that through.
The regexp thing wouldn’t bother me if there were at least one tool that could be used. On any standard POSIX system, there would be at least one way, and on most Linux distros, there’s a half-dozen relatively simple, installed-by-default tools that can do it. Bash, if nothing else.
But it’s like, in BB every tool excludes this ability. It’s frustrating, and of it isn’t regexp, it’s something else.
First thing I always do on a new Termux installation is setting up bash and GNU tools.
