Shell Scripting frameworks

I have developed a few scripts to help organize my work. One of those which I am both proud of and frustrated by is my 'app' framework:

I chose shell scripting because it runs on all platforms and is essentially glue. The readme there alludes to the same. As much as most places want to get away from shell scripting, it is so prevalent that I find it useful to build a framework around it.

The intent with this is:
1. provide a framework to write applications
2. provide easy-to-read logging
3. provide common functionality across platforms [install, run scripts, install go apps, npm apps, etc. ]
4. support features that can be enabled automatically or via configuration

The list goes on and on.

Some of the 'apps' I've built with this are for configuration management, wrapping secrets providers, and wrapping common git actions I routinely perform. The more complicated apps I've built with it are an automated freebsd installer and an automated gentoo installer.

That said, some of the challenges I face are library import handling is fragile. I essentially hard-code libraries for the install app and for downstream apps, I can pull libraries in.

I suppose, I'm looking for some guidance, or a code review. While I have thought about migrating to an actual programming language like go or Java, I stay away from those because running go in my workplace is not immediately possible, and while Java is readily runnable at my workplace, it introduces additional scrutiny whereas a shell script does not.

That leads me to another option which is to write the core framework in go or Java and instead produce a shell script as the output. I'm fluent in both go and Java, so that isn't a problem. My problem is how best can I design a shell-script framework with the limitations it imposes? Using go or Java simplifies things a bit because there are many tools that allow me to essentially just focus on the problem, the implementation. Whereas, if I write in shell natively, it'd be like me trying to write a C compiler.

Thanks for the read.
 
I'm just getting into shell scripting myself, but I'll give it a quick read.

*cllick-click*

From the readme:
Why gnu sed, gnu awk, gnu grep, etc.?

From install/freebsd/defaults/defaults:
why sudo?

There are zero comments in these files...?

I'm a bit confused, is this intended for *ME* (aka: someone other than you) to use? Because I don't think everyone wants GO, rust, python39, etc. installed.
 
Thanks for taking a look.

Good question, I am using those tools because with gnu grep, I can use Perl regex syntax. For Gnu sed, I am using the in-line replace feature. Now, I'm using coreutils since they're readily available on Linux, FreeBSD, Apple, and Windows in git bash.

As far as sudo, that's what I'm using to gain admin rights, perhaps doas might be better these days. Regarding sudo, I had also thought about making these strictly user tools that could live in a user's home directory by adding them to the user's path, but I would still need some way to elevate privileges to install other packages if a user wants a go package for example.

Yes and no, before I published the code to github, I stripped out anything that might contain sensitive information.

Regarding Go, Rust, Python, those are only installed if and when one of those packages is requested to be installed. So, for example, the install app itself does not install those tools, but if you right an app and list a go package, this will install go and then install that go package. So, in essence, it is a recipe to get those things bootstrapped. If you look at my bloated dev 'app' it installs a few go packages.

The way that works is by placing the go package to be installed in a go file under setup ...
 
Back
Top