Create robust CLI apps with Bashly - a tutorial

[meleu]

Here's my attempt to introduce more people to the power of Bashly:

https://dev.to/meleu/create-robust-cli-apps-with-bashly-5gb0

Any feedback is very welcome.

---

@DannyBen I said I would put it on the wiki but was unsure about where to put it. 😅

[DannyBen]

Wow - this looks like it was a lot of work....
On the Wiki, I think a new page called "Community Tutorials" or "Community Guides" or something similar would fit no?

[meleu]

done: https://github.com/bashly-framework/bashly/wiki/Community-Tutorials

[DannyBen]

I have followed it, and it is very nice. It is interesting to see this from the perspective of someone else :)

I wondered why are you using

if [[ "${args[--web]}" == 1 ]]; then

rather than just

if [[ "${args[--web]}" ]]; then

[meleu]

Good question. And I think I'm gonna change it to follow your suggestion.

---

Justification...

That's because I usually also use set -u in my "strict mode config" (actually set -Eeuo pipefail).

I could handle that with ${args[--web]:-} to make it not break with an "unbound variable", but I feel like comparing with 1 is less cryptic for "non-bash" people.

That being said, I must say that I'm not 100% sure that my current approach is the best choice for that tutorial.

I, indeed, see [[ "${args[--web]}" ]] as the most readable bash way to express the intention (except by creating a one-liner function with a descriptive name).

As I'm not using set -u at that point, I think I'm gonna update the tutorial to use your (simpler) approach.

[DannyBen]

I am using the default strict mode, only set -e - I see no reason to make life harder than it is :)

[meleu]

I only noticed the value of using set -u when I started working with scripts for CI/CD pipelines.

It's infuriating frustrating when it takes several minutes to realize you forgot to fill a variable or made a typo (a typo is detectable with shellcheck though).

Anyways, I agree that set -u doesn't belong to an "Introduction to Bashly" tutorial. 😅

[meleu]

@DannyBen (and anyone else) I also would appreciate your input about this...

One thing in the tutorial that is more my personal coding style than a "widely adopted" way of coding:

Passing arguments to functions rather than allowing them access $args directly.

I mean, doing this

generate_random_number() {
  local max_number="$1"
  # ...
}

# now I'm forced to call it with an arg
generate_random_number "$max_number"

rather than just

generate_random_number() {
  local max_number="${args[--max]}"
  # ...
}

# I don't need to pass any argument
# (it was handled by Bashly)
generate_random_number

The justifications for my style are:

• it's easier to write automated tests for functions with args than having to instantiate variables before calling the functions.
• I feel like the functions shouldn't depend on an external variable (my metaphor is more like: functions shouldn't be aware that they belong to a Bashly project)

But, to be honest, I'm not really sold on these ideas, and sometimes I feel like it's over-engineering.

What are your opinions about this?

[DannyBen]

Passing arguments to functions rather than allowing them access $args directly.

I think you are doing exactly the right thing. Here is how I see it:

1. The args array should be used (consumed) by the command code (e.g. src/root_command.sh).
2. Any lib function, should be designed as a function in any other language - it accepts arguments, and is agnostic to who called it and in what state.

Using this approach, the lib functions are unit-testable, and the command code itself is mostly a controller that takes the user input, diverts it to functions, and outputs the result.