So my project is implemented mostly in Bash. Initially I didn't create it specifically for OpenWRT but now seeing that it's working well on it, I moved in the direction of improving compatibility with OpenWRT in the hope that it'll be useful here. So at this point there are very few dependencies not shipped by default on OpenWRT which mainly consist of Bash, bc and comm (at least these were not shipped with the 2021 version but maybe you can tell me if the newer versions include these utilities be default). Bash is obviously the larger one. As it stands right now, Bash packages from the repository satisfy the dependency but the issue is of course that a Bash package weighs around 350KB (not sure how much it is after installation). So my question is, as the title states: is having Bash as a dependency a significant roadblock for most users, or is it Ok?
I don't think I'll be re-implementing the project in dash-compatible code so if it's a big roadblock then perhaps I'll give up. On the other hand, if it's not then the project is fairly close to full compatibility with OpenWRT.
It depends... depending on how resource intensive the rest of the project is that size might or might not matter to the users. This mostly is an issue for devices with low amounts of storage and no easy way to increase that storage. If the rest of the project aim at such low capability devices, bash likely will scare away a noticeable fraction of potential users, if however the rest requires a beefy router to run in the first place, I would assume that 350KB would be acceptable/in the noise.
Personally I like shell for its ubiquity, but I think that posix shell is just too feature poor... (his might or might not be on purpose, to steer bigger projects away from shell, but I rather wish for a shell with a full fledged programming language attached with a richer set of data types, and something that might even be compiled into an executable, one can dream can one not?)
That depends on which bash features are used though, some things are hard to translate from bash to posix shell. E.g. bash has direct access to a relative high resolution time information as a built in without having to call a binary, which makes generating timestamps at highish rates feasible.... dash, as far as I know, does not allow that... whether the OP requires any bash only features or not I can not say...
The project implements lots of error checking logic which is not very easy to translate to Dash. For one example, the "pipefail" feature. Also there is a fairly significant use of arrays, including associative arrays.
The project is working fine on my 10-year-old router with 8MB of storage, 128MB of memory and a single-core CPU. So I don't consider it very resource-hungry. It's a geoblocker, so most of the work is done by the firewall and my code is only responsible for fetching, processing and updating ip lists and providing an easy interface with the firewall.
I have greatly enjoyed working in bash for the cake-autorate project. So many useful features. And see this positive field report for a 2013 Archer C7 - that's a ten year old router. It is hard for me to imagine many use cases employing weaker routers such that the footprint of bash is a showstopper.
Is it easy to switch to bash as the default shell in OpenWrt? If so, I think I'll do so on all my devices.
The OpenWrt minimum requirements are still 8/32 (with 8/64 preferred), see https://openwrt.org/supported_devices, OpenWrt really only ended support for 4/32 devices in 2022.
That said banIP offers similar functionality, so if banIP requires less storage one could steer low storage router users to banIP instead and focus on less constrained devices... in the end very low end devices will eventually age out usage, but we clearly are not there yet... (and even on an 8 MB storage router, 350KB is still a sizable chunk)
Well, changing the default shell is not required for my project. Technically Bash is just a dependency like any other dependency. Considering a typical low-end router has at least 8MB storage and perhaps at least 4MB free storage (before installing extra stuff), is using 10% of the free capacity such a big deal?
Having used linux on very low-end systems in the past (case in point, a SUN SPARCstation with a 1*50 MHz 'SM50' SuperSPARC CPU, 160 MB RAM), bash is a rather heavy shell. To the extent that it made me switch my login shell to busybox ash (better for interactive use than dash), as opening xterms or connecting via ssh took around 10s (compared to virtually instantly). Also keep in mind that few people who might find interest in your project (geo location) are likely to be interested in that for itself, but rather in combination with other server-like tools (to reduce their attack surface), so >=0.5 MB more or less might make it or break it.
The above does not imply that you should port it over to plain POSIX shell, just to point out that bash is a rather heavy dependency for anything that doesn't really need it (in the sense of profitting significantly from its unique features). Having ported a lot of long-standing code from bash to POSIX shell over the years, I rarely encountered things that really did so.
I made a search for "bash" dependency in the packages feed repo packages.
Out of the approx. thousand different packages, there is just one package "msmtp" that depends on bash. Others just take the normal shell.
So, dependency on bash is possible but extremely rare.
Yup, and taking a bigger sample shows even lower frequency. I get 4 distinct bash dependencies in ~10k packages (x86 23.05.2).
$ opkg list | sort -u | wc -l
9939
$ opkg -A whatdepends bash
Root set:
bash
What depends on root set
cache-domains-openssl 2.3.1-2 depends on bash
msmtp-queue 1.8.24-1 depends on bash
strongswan-gencerts 5.9.11-1 depends on bash
cache-domains-mbedtls 2.3.1-2 depends on bash
cache-domains-wolfssl 2.3.1-2 depends on bash
checksec 2.5.0-1 depends on bash
All right, thanks everyone for your answers. The situation is clear now. In the meanwhile, I made a test implementation of arrays in POSIX since my project heavily depends on arrays and I would rather really not re-write everything, at least not at once. I'll see how it goes.
Eventually, after quite a bit of work, I converted the project to POSIX-compatible code. Man, what a task. Quite educational, though. Most of the code that was previously using arrays was converted with the usual POSIX string manipulation techniques, however some would be rather messy this way, so the aforementioned POSIX arrays implementation turned out handy. After the conversion, the scripts also work much faster, which is a nice bonus.