Bash-lib: Library for bash utility methods and tools(github.com)
github.com
Bash-lib: Library for bash utility methods and tools
https://github.com/cyberark/bash-lib
24 comments
There's also the "pure bash bible", which is a collection of pure-Bash alternatives to several commands: https://github.com/dylanaraps/pure-bash-bible
We need a Bash package manager and global repo now!
(If you had told me in 2001 that Javascript would have had NPM and bash not, I would not have believed you.)
(If you had told me in 2001 that Javascript would have had NPM and bash not, I would not have believed you.)
If you can afford using a package manager then you can afford using something more sophisticated than bash.
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.
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.
I can see in the use case of building up scaffolding between many different Unices to a common reference point sufficient to serve as an abstraction layer for a packaged software product to code against a generic Unix model, a Bash package manager might be useful. Some of those Bash-based abstraction layers can get relatively sprawling, and a packaging system would serve a useful role as a configuration dispatcher.
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.
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.
What is “reasonably close”?
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”.
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”.
> bpkg is a lightweight bash package manager. It takes care of fetching the shell scripts, installing them appropriately, setting the execution permission and more.
> 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".
https://github.com/bpkg/bpkg
---
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
> 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".
https://github.com/bpkg/bpkg
---
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
>has been forked should anybody be interested https://github.com/bats-core/bats-core
Is this the maintained fork you've linked to?
Is this the maintained fork you've linked to?
Funny you asked, build2[1] can be (and is[2]) used to package bash. It even has build system support for modularization of bash scrips[3].
[1] https://build2.org
[2] https://cppget.org/?packages=bash
[3] https://build2.org/build2/doc/build2-build-system-manual.xht...
[1] https://build2.org
[2] https://cppget.org/?packages=bash
[3] https://build2.org/build2/doc/build2-build-system-manual.xht...
Interestingly, the legacy debian-installer is based on a package manager called anna (Anna's not nearly Apt), where most of the installation steps are implemented as postinst bash scripts of various udeb packages: https://salsa.debian.org/installer-team/anna#README
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.
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.
At my company, for what we deploy as Bash, we take care to write it according to regular software engineering standards (code + tests + doc), build OS-specific packages, distribute them using proper repos (rpm, deb) and bake them into vm machine images/containers where needed. We declare dependencies between packages to specify (versioned) dependencies between different code libraries. Works for us.
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.
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.
Did this precisely at my previous company doing platform automation. It works but requires upkeep.
Check out Basher: https://github.com/basherpm/basher
I think what we really want to fit the use case for shells is an ad hoc package standard that apt, dnf, etc can recognize.
Shameless plug but I was not a huge fan of working with bash as I liked python, so I made Sultan: https://sultan.readthedocs.io/en/latest/
Gotta admit, that syntax is a lot easier on the eyes than subprocess.
Thanks for this, very interesting!
pyinvoke (used by fabric, which ansible uses iirc) in in the same vein
This seems very interesting, however also dangerous.
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.
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.
Why is that dangerous? I mean I have seen tons of things in python where I'd say "Why didn't you just do this in bash.
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.
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.
I mean, there is some things that Bash really shines, specially for gluing code or working with pipelines.
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.
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.
Shameless plug: https://bitbucket.org/koalephant/shell-script-library
Yes, I know the readme is not up to date with recent changes/improvements.
Yes, I know the readme is not up to date with recent changes/improvements.