Maintainer Volunteering Needs

[nntoan]

Dear OMB community & @ohmybash/collaborator,

Since 2017, this repository was set up just for my personal usages and it was received welcome and real usages from people around the world. So happy about that!

However, I'm having difficulties with maintaining the repo as you might notice. We appreciate it if you volunteer to join as maintainers of the project.

Make OMB Great Again!

Thanks all.

[akinomyoga]

I'm not actually using oh-my-bash for myself, but I am watching this repository because I sometimes receive issue reports related to oh-my-bash in my repository ble.sh. Since it seems like there are recently no other active people in oh-my-bash who regularly make comments to the issues and PRs of oh-my-bash, maybe I can process some of the issues of high priorities.

Nevertheless, I think I'm not a proper person who handles the PRs for the new features, so I rather feel we also need other people who can help to review the PRs of new features. I remember that when I started to watch the repository, @Kreyren has been one of the active people. I'm not sure if @Kreyren still uses oh-my-bash and recently has time to participate in the maintenance of oh-my-bash, but I think we may ping @Kreyren whether if @Kreyren is willing to become one of the maintainers (Or might be already one of the collaborators?).

[Kreyren]

I'm not sure if @Kreyren still uses oh-my-bash and recently has time to participate in the maintenance of oh-my-bash, but I think we may ping @Kreyren whether if @Kreyren is willing to become one of the maintainers (Or might be already one of the collaborators?).

Still using components of it and i have it in TODO to work on the project, but i lack the time frames atm... and i want to refactor the whole project when i get time frame tbh.

POSIX compatibility is important as it makes oh-my-bash more functional without loosing functionality or making the code harder to read.

The issue with oh-my-bash contributors that i can see so far is that majority of them lack the required experience and skills to understand that and learn how to write in POSIX syntax.

Do we really need to require POSIX compatibility? I already see many Bash extensions in oh-my-bash.sh such as arrays, local and [[ ... ]].

Arrays: None should be using them in shell scripting as if you need to use them then shell is probably not the language you want to you for your usecase, but we can do string manipulation or make a helper to do arrays in posix-compatible way as needed e.g. making a variable that stores the array elements as var="one:two:three:four" and then regexing/greping what we need.

local: Two ways:

1. subshell -> Painfully inefficient avoid at all cost
2. define variables as keyword_something=... and then do unset keyword_* which requires the code to be written as more robust to work.

[[ ... ]]: just do [ ... ] and use case for ~=-like operators functions which makes the code much more readable and functional.

Note that bash supports POSIX shell so by using posix shell we are making functionality for bash.

[Kreyren]

Note: I am not against merging NON-posix contributions assuming that they do not prevent POSIX sh from working and are clearly tagged/labeled to be rewritten in posix-compatible.

[akinomyoga]

@Kreyren I'm glad to hear from you! I'll later reply to these comments!

[nntoan]

Another related question is whether there is a minimal version of Bash that we support. For example, the version of the default Bash in macOS is still bash-3.2, so I think it would be bash-3.2 as far as we do not require users to install the latest version of Bash through Homebrew or what else. Or, if we can expect a newer verion of Bash, 4.2 would be a good candidate because the latest version of bash-completion requires bash-4.2 for some important features such as (global) associative arrays.

Yes, I'm planning to remove the strict of v4 in the installation script and keep the bash-3.2 as a minimal version (as per the beginning of the project), it's pretty annoying to force user to install another version of Bash.

Do we really need to require POSIX compatibility? I already see many Bash extensions in oh-my-bash.sh such as arrays, local and [[ ... ]].

Agree, ignore the POSIX, it's nice to have not to be required here as the whole project is for Bash. In the past, it's required for me as sometimes I'm using this inside Git Bash, now we have WSL in Windows so yea POSIX compatibility is optional for the project.

[akinomyoga]

Hmm, I see the divergence of opinion here. Anyway, my suggestion is to allow the Bash extensions, i.e., oh-my-bash will use POSIX + the Bash extensions. I don't think we need to allow requiring non-POSIX external commands.

---

@Kreyren

Still using components of it and i have it in TODO to work on the project, but i lack the time frames atm... and i want to refactor the whole project when i get time frame tbh.

I see. Thank you for sharing your consideration with us! I see most of #70 would be worth incorporating into the master, so I'd like to take over the adjustment of the PR. Before making larger changes to oh-my-bash, I would like to merge the PR after addressing the small issues I wrote there just several hours ago.

POSIX compatibility is important as it makes oh-my-bash more functional without loosing functionality or making the code harder to read.

Just to make it clear, I was talking about the POSIX-shell features. I agree that we should confine ourselves within POSIX for external commands, which don't necessarily there in all systems.

The issue with oh-my-bash contributors that i can see so far is that majority of them lack the required experience and skills to understand that and learn how to write in POSIX syntax.

Hmm, yeah. Right, that's the problem. I guess most people with skills and experiences would use their own configuration but do not rely on an external pack of configurations like oh-my-bash. For example, I don't use oh-my-bash nor bash-it and will unlikely to use them either in feature.

Arrays: None should be using them in shell scripting as if you need to use them then shell is probably not the language you want to you for your usecase, but we can do string manipulation or make a helper to do arrays in posix-compatible way as needed e.g. making a variable that stores the array elements as var="one:two:three:four" and then regexing/greping what we need.

I partly agree with it. If we are writing some tools independent of the shell behavior, it's probably better to use other languages if we are trying to intensively use the rich features of Bash. But I don't think that also applies to the shell configuration, for which the external process written by other languages needs to struggle with communicating with the Bash process. For example, oh-my-bash uses arrays to let users specify a set of plugins and themes that the user wants to enable, as we can observe in templates/bashrc.osh-template#L46-L71, which I don't think can be a reason for rewriting the Bash configuration in another language.

local: Two ways:

1. subshell -> Painfully inefficient avoid at all cost
2. define variables as keyword_something=... and then do unset keyword_* which requires the code to be written as more robust to work.

The former is painfully inefficient as you say, and the latter is, I would say, not maintainable at all. This is just a source of bugs or namespace leaks.

[[ ... ]]: just do [ ... ] and use case for ~=-like operators functions which makes the code much more readable and functional.

Some might be more readable by requiring less knowledge from the users, but I don't think blindly sticking with the POSIX-shell features would lead to readable and functional codes. I rather think it's likely to be the opposite. For example, let's consider the above example of var="one:two:three:four". In this case, we may write the matching in something like the following way.

# with Bash extension
if [[ :$var: == *:one:* && :$var: == *:three:* ]]; then
  echo "options 'one' and 'three' are enabled."
fi

# with only POSIX-shell features (1)
case ":$var:" in
  *:one:*)
    case ":$var:" in
      *:three:)
        echo "options 'one' and 'three' are enabled." ;;
    esac ;;
esac

# with only POSIX-shell features (2)
if
  case ":$var:" in *:one:*) true ;; *) false ;; esac &&
    case ":$var:" in *:three:) true ;; *) false ;; esac
then
  echo "options 'one' and 'three' are enabled."
fi 

I hardly think the POSIX versions are more readable and functional than with the Bash extension. We may still encapsulate the pattern matching in a shell function with POSIX, but that just requires the user's knowledge about the function instead of the knowledge about the Bash construct.

Note: I am not against merging NON-posix contributions assuming that they do not prevent POSIX sh from working and are clearly tagged/labeled to be rewritten in posix-compatible.

I'm a bit confused. Is the reason you push the POSIX shell the readability and functionality? Or, do you actually intend to make oh-my-bash work in any POSIX shell? I'd say writing literally everything in the POSIX shell (taking into consideration an arbitrary combination of set -uef, etc) is just pain.

---

@nntoan

Yes, I'm planning to remove the strict of v4 in the installation script and keep the bash-3.2 as a minimal version (as per the beginning of the project), it's pretty annoying to force user to install another version of Bash.

OK, thank you for your reply! Then we can use some of the version-specific features such as printf -v var, var+=value, and arr+=(elements), that older Bash doesn't have.

Agree, ignore the POSIX, it's nice to have not to be required here as the whole project is for Bash. In the past, it's required for me as sometimes I'm using this inside Git Bash, now we have WSL in Windows so yea POSIX compatibility is optional for the project.

My Bash project (which intentionally doesn't require external non-POSIX commands) uses full of Bashism but seems to work in Git Bash (according to users). I believe as far as we only use POSIX plus the Bash extension, it should work also in Git Bash.

[akinomyoga]

@nntoan I think we need to discuss more how oh-my-bash should be maintained in this chance. Sorry for bothering you, but I would like to finish this kind of discussion at once in this chance in order not to bother you later.

Naming convention for config variables: Why OSH?

I have come up with this question in #266. It seems like all the related variables exposed to the users for configuration purposes have the form OSH or OSH_*. Is there any rationale for this convention? I think it would be more sensible to adopt the form OMB_*. Also, what do you think of switching to the prefix OMB_*?

For the compatibility for the users who have used the existing versions of oh-my-bash, I think we can just write like

: "${OMB_CUSTOM=${OSH_CUSTOM}}"

in the beginning of the script to load the compatibility configuration.

FYI, the original ohmyzsh seems to use just ZSH_ for the prefix, which I don't think is a good idea.

For the lowercase omb vs osh, I find both instances in the codebase:

./plugins/git/git.plugin.sh:15:  if ! $_omb_git_git_cmd rev-parse --is-inside-work-tree &> /dev/null; then
./plugins/git/git.plugin.sh:18:  echo $($_omb_git_git_cmd remote -v | cut -d':' -f 2)
./tools/install.sh:85:  " $HOME/.bashrc > $HOME/.bashrc-ombtemp
./tools/install.sh:86:  mv -f $HOME/.bashrc-ombtemp $HOME/.bashrc
./tools/uninstall.sh:19:    bashrc_SAVE=".bashrc.omb-uninstalled-$(date +%Y%m%d%H%M%S)";
./tools/check_for_upgrade.sh:9:function _update_osh_update() {
./tools/check_for_upgrade.sh:13:function _upgrade_osh() {
./tools/check_for_upgrade.sh:16:  _update_osh_update
./tools/check_for_upgrade.sh:37:      _update_osh_update && return 0;
./tools/check_for_upgrade.sh:43:        _upgrade_osh
./tools/check_for_upgrade.sh:48:          _upgrade_osh
./tools/check_for_upgrade.sh:50:          _update_osh_update
./tools/check_for_upgrade.sh:56:    _update_osh_update

I think we should also define the naming conventions for the shell functions.

[Kreyren]

FWIW shell is designed to be a very dumb and simple language and we are using it to do library management as a package manager and other complicated tasks which i see as malpractice due to the unsustainable resource requirements for maintenance with each new function/feature we add that is limited on platform compatibility.

Thus i would argue for declaring abstract for what should be in oh-my-bash to avoid wasting resources and defining the package/library management in more sustainable language such as GNU Guile or Rustlang (meaning to e.g. use GNU Guile to manage the shell libraries and their exports i am NOT proposing to make something like oh-my-guile..).

[nntoan]

Yea, it should be OMB then. I've created this branch: feature/omb-improvements to have #73 as our 2nd major refactor for the project.

[akinomyoga]

@Kreyren

Thank you for your comments!

FWIW shell is designed to be a very dumb and simple language and we are using it to do library management as a package manager and other complicated tasks which i see as malpractice due to the unsustainable resource requirements for maintenance with each new function/feature we add that is limited on platform compatibility.

I roughly agree with the statement, but what do you mean by "unsustainable resource requirements"? I don't think Bash will be unmaintained in near future, and even if Bash would be deprecated, I don't think we need to care about it for oh-my-bash because it is primarily designed to be used with Bash.

Thus i would argue for declaring abstract for what should be in oh-my-bash to avoid wasting resources and defining the package/library management in more sustainable language

I agree, but I don't remember any issues/PRs which is trying to do complicated things that should be implemented in other languages.

such as GNU Guile or Rustlang (meaning to e.g. use GNU Guile to manage the shell libraries and their exports i am NOT proposing to make something like oh-my-guile..).

I don't understand why you have specifically raised these languages. I don't remember whether I've ever heard of the name "GNU Guile", and also doubt if it's available in proprietary systems such as macOS, Solaris, AIX, etc. by default. I don't think strongly-typed languages and compiler languages such as Rust are appropriate for managing the shell configurations. The configurations are usually pretty dynamic things and also just a set of variables plus some small independent functions. I'd like to avoid requiring users to install the GNU Guile interpreter, the Rust compiler, or some other interpreters/compilers just for the Bash configuration considering that Bash may be used in some microcomputers or in very old systems.

Also, the shell configuration is sometimes tightly bound to the shell state itself by interacting with the current working directory of the shell, the value of shell variables, etc. How do you intend to interact with Bash for such a configuration using other languages? It is in principle possible e.g. by writing command server in Bash script and accessing the server from Rust clients (which ironically requires the complicated Bash implementations that we want to refrain from), or by writing a loadable builtin for Bash (which is unavailable with the systems that do not provide proper POSIX support for dynamic libraries such as Cygwin, MinGW, MSYS2, Git for Windows, etc.).

[Kreyren]

but what do you mean by "unsustainable resource requirements"? I don't think Bash will be unmaintained in near future, and even if Bash would be deprecated, I don't think we need to care about it for oh-my-bash because it is primarily designed to be used with Bash. -- @akinomyoga (#268 (reply in thread))

I doubt that bash will be deprecated anytime soon.. at least until nushell is finished

I was talking about the solution itself as code in bash/posix sh is usually significantly more complicated in comparison to other languages thus adding more features exponentially increases the workload needed to maintain it.

I don't understand why you have specifically raised these languages. -- @akinomyoga (#268 (reply in thread))

I hate wasting time and i find these to be the most efficient for their respective use (GNU Guile for extensibility and rustlang for backend and runtime-demanding tasks).

I don't remember whether I've ever heard of the name "GNU Guile" -- @akinomyoga (#268 (reply in thread))

It's very popular variation of scheme lisp mainly used by the GNU project and in free software development e.g. you find it in GNU Gimp, GNU Guix, etc..

Also, the shell configuration is sometimes tightly bound to the shell state itself by interacting with the current working directory of the shell, the value of shell variables, etc. How do you intend to interact with Bash for such a configuration using other languages? -- @akinomyoga (#268 (reply in thread))

i don't want to change the interaction that is fine.. just the deployment and management.

[akinomyoga]

I was talking about the solution itself as code in bash/posix sh is usually significantly more complicated in comparison to other languages thus adding more features exponentially increases the workload needed to maintain it.

Oh, I see! Thank you for your clarification! But in that case, I actually think we don't have to worry about it too much. I meant by the new features new themes, new plugins, and new completions, which are all not-so-large and independent of one another. It's far from a tightly-coupled system, so essentially we don't have to take care of the consistency between these features. As we don't have to think about the combination of different features basically, I expect the maintenance cost will only increase by linear in most cases.

The package management part is just implemented in oh-my-bash.sh and is essentially just sourcing scripts in order. Currently, I don't see any issues/PRs for new features of this main script and don't plan to add any fancy features by myself either.

i don't want to change the interaction that is fine.. just the deployment and management.

So, are you saying those statements are actually irrelevant specifically for oh-my-bash? Then, that's fine. I agree with it in general that we want to implement real programs using appropriate languages.

[HanJoHibender]

Hi people,

Can I help in any meaningful way @nntoan ? I can update some of the wiki/docs first, as I am active user of oh-my-bash I'd like to contribute. I do have basic understanding multiple langauges and language structures/design choices, however for shell I'd have to dig in a bit first.

Kind regards,
Hanjo

[akinomyoga]

Maybe you do not expect me to reply, but let me leave comments because there doesn't seem to be a reply from @nntoan. If you are still interested in contributing to oh-my-bash (OMB), any help is always welcome. Currently, there are only two maintainers effectively, and I am the only active one. In addition, I'm actually not a user of OMB as I have mentioned above. so I do want constant feedback from any OMB users in processing incoming PRs and Issues.

I can update some of the wiki/docs first,

I think you can already edit Wiki pages. We allow any users to edit the wiki pages. If any help is needed, please report it here or in a new issue. As for the documents in the repository, please submit a PR.

You can find other parts you might contribute to by the help-wanted tag of Issues.

Also, I would like more maintainers who review and resolve incoming PRs and Issues. If you are willing to process them, please first Watch this repository from the top right button of the repository page. Then please leave comments and reviews in PRs and Issues. You can also submit PRs to resolve Issues. After processing incoming PRs and Issues for a certain period, if you think you are comfortable with offering constant and long-term support, I can recommend you for a member of maintainers.

however for shell I'd have to dig in a bit first.

Don't worry. I'll check PRs for the shell language, which is a rather trivial part. What is non-trivial for me is to evaluate the usefulness of PRs (since I'm not an actual user of OMB). For example, it is non-trivial for me to judge whether a particular PR suggesting a new feature is useful and worth merging.