UX & maintenance: Refactor bash scripts in a more reliable shell language

[fiftydinar]

Intro

This also includes just scripts, which utilize bash.

The goal is to make scripts more reliable & easier to maintain in the future.

While current bash scripts are reliable enough, there is still some area where this can be improved.

Why shell language & not dedicated programming language?

Because shell language is easier to learn & maintain for simple scripts.

Which shell language to use

I aim to use Oils (formerly OilShell):
https://www.oilshell.org/

I find it a great candidate due to these reasons:

• OSH shell mode: I can still code in pure Bash code, while gaining better logging + debugging support & some other minor features & improvements, which can make Bash code quality better. This is possible thanks to POSIX & Bash scripts compatibility.
• YSH shell mode: It's a more radical Bash successor with major improvements like proper error handling & such. It doesn't deviate from Bash a lot, especially in terms of syntax, which I really like.

Other similar shell languages to bash like fish or zsh don't contain enough improvements for me to use it.

Radically different shell languages like nushell & others are not for me, since I like Bash syntax better as I can understand & read it easier.

Here's the Oils developer take on nushell vs oils (old & probably inaccurate about some nushell issues):
https://www.reddit.com/r/ProgrammingLanguages/comments/ddhmj9/comment/f2htup3/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

BlueBuild modules

Currently, the policy for making official BlueBuild modules is that they should be written in bash.
This can change over time, as there is a discussion regarding using more reliable language for official BlueBuild modules:
blue-build/modules#212

• wallpapers
  Most notable case of bash complexity is inside unofficial build-time wallpapers BlueBuild module, made by me, which is the most complex BlueBuild module I know.
  It's tough to debug, fix or improve things in the script due to its complexity.
  However, it works & it's reliable, so that's good.

  Features that I wanted to add for it to become official bash module is support for advanced wallpaper features of other desktop environments, like KDE. This is non-needed for Gidro-OS, since Gidro-OS is Gnome-based, but official BlueBuild module must conform to any user as much as possible.

• default-flatpaks
  This is the 2nd most complex boot-time BlueBuild module.

  Boot-time modules are specifically important to be as reliable as possible, due to the fact that they run & perform its functionality on booted system.

  This one will be refactored in the future in bash, as official BlueBuild modules must be written in bash. However, I believe that usage of more reliable language in refactoring is more suitable for this module than writing it in bash.

  There are some existing issues with it, which should be solved for ideal experience:
  fix(default-flatpaks): Add error-check & validation of flatpak IDs in build-time blue-build/modules#169
  feat(default-flatpaks): Prompt & explain the user new flatpak install & uninstall blue-build/modules#188
  refactor(default-flatpaks): Support multiple repos blue-build/modules#146
  fix(default-flatpaks): Module does not add flathub remote when not explicitly specified blue-build/modules#166
  fix(default-flatpaks): Flatpak IDs input in the last module definition overwrites the 1st one blue-build/modules#231

Just scripts

While those work relatively well, I believe they can be improved.

The biggest issue is that just scripts currently look messy.

While reliability of those are alright, I think that it can be improved, to account for other possible scenarios.
Better shell language would make this maintenance easier.

[xynydev]

You could add your case for oil / ysh in the alternative shell discussion for BlueBuild, since there's no consensus yet.

[fiftydinar]

You could add your case for oil / ysh in the alternative shell discussion for BlueBuild, since there's no consensus yet.

I added initial impressions on it, will tell more when I get more deep into it.

[fiftydinar]

To improve just scripts readability, I can put them in organized folder like: /usr/libexec/gidro-os-just-scripts/.
Those scripts shouldn't be executed directly by the binary name, so that's why they should be in /usr/libexec/, rather than in /usr/bin/.

So those just scripts will instead manually call those bash binaries with all the code content in 1-liner.

This would allow to reformat just scripts to look cleaner with newlines, which are not allowed in just syntax.
It would also show bash syntax properly in the Text Editor, which would help me to code better.