Named parameter named 'command' does not get evaluated

[nkakouros]

Here is an example script:

#!/bin/bash
source "lib/oo-bootstrap.sh"
import "../Ethical Hacking/EN2720/scripts/vendor/bash-oo-framework/lib/util/namedParameters.sh"

function q {
   @required [string] command
   echo "${command-UNDEFINED}"
}
q 'some value'

Running this prints 'UNDEFINED'.

[niieani]

Fix is here, in the rewrite of the named parameters functionality: https://github.com/niieani/bash-oo-framework/issues/41#issuecomment-362107200. To get it merged I'd need to provide a backwards-compatible layer for the older syntax, I didn't have time to do it yet. Unless we do it as a breaking change and release 3.0. What do you think?

But it works with the new version:

function q {
   args : @required string command
   echo "${command-UNDEFINED}"
}
q 'some value'

Prints: some value

[nkakouros]

I was thinking about this for quite some time. Here is my suggestion.

Version 2.0 receives no further features, fixes, etc except those that are critical and no easy workaround can be found. For instance, for the issue here you can easily rename 'command' to 'command_name' or sth else. Or for #41 you can end all named parameters sections in functions with a : and you are good to go.

For version 3.0 onwards, I suggest a slight change in the development approach. I think that we should aim for the framework to be written from scratch. Just to not create unwanted impressions, what you have already achieved is one hell of a clever project and I still stand in awe of your achievement. By rewriting, I simply mean to start from an empty state, not try to just patch the previous version. We can start from the entry point of the project (oo-bootstrap) and move to each module one by one. Code reuse could, will and should happen, but at every step there should be 3 criteria on whether to commit (old or new) code:

1. Code is sufficiently documented: Comments on difficult hacks, on what info some key variables hold, how some functions work, etc should IMO be included. We could also use (and extend) sth like this and have a really well documented project. This could lower the entry barrier for new contributors, as well.
2. Code is thoroughly tested: We should try to have as good test coverage as possible. Bash infinity is one hell of a project with great logical complexity and there are many edge cases. Having tests that go through every small or big part of functionality will give as assurance that our approaches are correct and will also bring confidence to potential users that the framework is stable. There could also be a CI process in place.
3. Code should be >adjective-here<: By that I mean we should try to write clean, short code that follows a consistent coding style, ideally is benchmarked, etc. The unofficial strict mode could also be adopted.

While developing, tools like shellcheck, shfmt, etc could be used to help produce as quality code as possible. Also, a git workflow (eg gitflow) could be adopted.

Moreover, it seems important to me to place Bash Infinity into a broader ecosystem of bash projects and cooperate with some significant ones (like BATS or go-script-bash). Technically, this translates into two things:

1. Making integration easier with such projects should be a consideration.
2. Functionality that is already covered by other such projects, should not be repeated, unless we feel that Bash Infinity's approach is better. For instance, BATS is a complete testing framework. Having our own, does not really add value to the end user and is an extra burden on maintenance. Instead, we could make it as easy as possible to integrate Bash Infinity with that project as per 1. . On the other hand, go-script-bash has an import functionality similar to Bash Inifinity. However, the approach there wouldn't suit Bash Infinity's needs, plus Bash Infinity's approach is more flexible.

Another issue to consider is platform and bash version support. From my point of view, someone that wants to use Bash Infinity to develop a bash project will have no problem updating their bash version to the latest available. It would be surprising to see someone choose to develop a whole project/application in Bash plus try to reduce development pain with the use of a framework and yet have issues updating their bash version. Thus, I think that development should be more or less done against the latest Bash version.

Finally, sth that is more like a wish of mine is to make it easier to use the project by providing stuff like syntax highlighting and auto-completion files for eg vim or atom.

The above are some thoughts I have been having and if you agree on some we could further discuss them and act upon them. Time is a scarce resource but there is no hurry here. I am interested and willing to help build little by little the new version.

[niieani]

Great points @tterranigma!

I wholeheartedly agree about the clean-slate and all of your criteria for it.

Just as I've started with the re-write of named parameters -- a clean slate here really helped to create a much shorter and easier to understand code.

Similarly, I've been experimenting with a better importing system, which does not pollute the global scope. See the example here.

Regarding your last point, I've also been exploring the "better tooling" avenue -- the experiment was to try and re-use tooling from a different language. My first try is to adapt TypeScript, i.e. use a limited set of expressions and emit clean bash.

It's a wild project, but I've already got something running locally -- it's a different take on the issue, and possibly a separate project to Bash Infinity.

But going back to the idea of 3.0 -- let's do it! 🔥