Bash-lib: Library for bash utility methods and tools
github.com
github.com
(If you had told me in 2001 that Javascript would have had NPM and bash not, I would not have believed you.)
> You can install shell scripts globally (on /usr/local/bin) or use them on a per-project basis (on ./deps/), as a lazy-man "copy and paste".
---
Also bash-lib is using bats (Bash Automated Testing System) for verification, which is un-maintained and has been forked should anybody be interested https://github.com/bats-core/bats-core
Is this the maintained fork you've linked to?
The whole point of bash is that it’s ubiquitous: be it an air-gapped embedded system, a recovery image or a full desktop environment, you can count on it having either bash or something reasonably close, no strings attached.
Introducing a Rube Goldberg package manager would go against this.
Instead of a bewildering array of case/if statements for each architecture/distro in every script, the package manager stores and deploys the platform-specific scripts, and make reading/maintaining them more streamlined. Then your case/if selection of the platform-specific environment is centralized into a single centralized location where the package manager call for installation is made.
I agree however that in an in-house setting, if I had the choice to use a package manager, then I'd be choosing a language other than Bash.
Bash isn’t necessarily gonna be installed on a bsd system and it’s not exactly recent on macOS - it’s possible it’ll be dropped there too.
I’m not saying don’t write shell, I’m saying don’t assume bash specifically is available.
There’s only one bash, but there’s plenty of shells that implement POSIX “sh”.
However, there's little documentation for any of this, and it's clearly not intended to be used for anything outside of the installer context— I couldn't even figure out how to do the equivalent of a debootstrap for an anna environment. For my own custom installer needs it turned out to be easier to use a conventional deb/apt environment and implement most of the logic in Python.
[2] https://cppget.org/?packages=bash
[3] https://build2.org/build2/doc/build2-build-system-manual.xht...
Looking at how e.g. some official AWS code is written and distributed in shell (like ec2-instance-connect-config), that's not too far I guess from how even big orgs handle Bash code.
I mean, this seems to make Bash a modern programming language, however if you do need something like this a modern scripting language like Python would be better in those cases.
Neither python nor bash exclude the other. Some things are easily solved in one, others are more easily solved in the other. And both have "escape hatches" to the other.
However, not rarely this ends in a trap: "oh, I already have this small shell script here, I will just add another feature". After sometime, you get a gigantic shell script full of lines that nobody understand anymore, since Bash lacks so many things as a programming language that you end up with multiple hacks just to support that feature you wanted.
I went with the trap above more than once, and sometimes I get myself in it again, until I decide that enough is enough and just rewrite the script in something else.
Yes, I know the readme is not up to date with recent changes/improvements.