Bash Plugin breaks with bad substitution on CentOS/RHEL 7

[markusdd]

These systems use bash 4.2. There is no @Q parameter expansion (I think it came in 4.4).

Result is as soon as the start routine is called I get a ${$@Q} bad substitution error.

This is a very common enterprise OS that is very widely used, so we should look into supporting that somehow.

[markusdd]

Just did a 'quick fix' and threw out all the @Q statements, works now. Maybe need to look if we now need to quote once more somewhere but seems ok at first glance

[romkatv]

I'm working on a proper fix. Shouldn't take too long...

[markusdd]

much appreciated

[romkatv]

Fixed. Tested with this:

docker run -e LANG=en_US.utf8 -e TERM -it --rm centos bash -uexc '
  cd
  yum update -y
  yum install -y git
  git clone --depth 1 --single-branch https://github.com/romkatv/gitstatus.git
  echo "source ~/gitstatus/gitstatus.prompt.sh" >>~/.bashrc
  cd ~/gitstatus
  exec bash'

[markusdd]

Excellent. Thank you!

[romkatv]

By the way, have you tried gitstatus.prompt.sh (see the docker command above)? Is there a noticeable difference in bash startup or prompt latency compared to bash-it?

[markusdd]

bash-it is certainly slower. This is simply due to the fact that it does much more in addition depending on enabled themes and plugins. I discovered e.g. the battery prompt costs quite some time and should be disabled on machines where there is no battery, as the failed calls in the background cost about 300ms.

I mainly use bash-it because of it's modularity and some very useful comlpletion and alias plugins. I also like the multiline-powerline a lot. It's also extensible quite well. And its SCM prompt is multi-SCM capable, which is useful to me as I sometimes have to deal with a few hg or SVN repos.

For anyone who needs just a fast useful prompt your implementation totally does the thing.

[romkatv]

bash-it is certainly slower.

Thanks, that's good to know. I don't use bash myself but sometimes my bash-using friends ask for advice.

This is simply due to the fact that it does much more in addition depending on enabled themes and plugins. I discovered e.g. the battery prompt costs quite some time and should be disabled on machines where there is no battery, as the failed calls in the background cost about 300ms.

I use zsh with Powerlevel10k, which, I think, is more powerful and more flexible than bash-it. It has battery, too. It's as fast as the simple gitstatus.prompt.sh prompt even if you pack your prompt with information to the brim (nvm, kubernetes context, public IP address, etc.)

There is nothing special in zsh that makes it possible to implement a feature-reach prompt that is instant. It's just careful coding. I think the same thing can be done in bash.

I mainly use bash-it because of it's modularity and some very useful comlpletion and alias plugins. I also like the multiline-powerline a lot. It's also extensible quite well. And its SCM prompt is multi-SCM capable, which is useful to me as I sometimes have to deal with a few hg or SVN repos.

Makes sense.

Is it possible to use completions from bash-it while having prompt defined by some other library (or hand-rolled)? These seem to be independent.

For anyone who needs just a fast useful prompt your implementation totally does the thing.

FWIW, gitstatus.prompt.sh and gitstatus.prompt.zsh are meant to be examples of how to use the API. Few people actually source them. There are several themes for zsh that are integrated with gitstatus (in zsh parlance "themes" are libraries that define your prompt). I believe there are none yet in bash. bash-it might become the first if your PR gets merged.

[markusdd]

Let's put it like this: I stripped down the number of plugins and prompt components I use and together with gitstatusd it is now blazing fast. There are some areas in bash-it which can be improved. There is still a lot of subshell forking going on, but gitstatusd alone has brought this down to a very reasonable level, as the SCM part is some of the worst regarding this.

I personally would switch to zsh anyway, but especially at work this is not an option, as too much proprietary 3rd party tools rely on the presence of a csh or bash. In zsh many things bash-it emulates are standard or much easier to integrate. The pre-exec hooks alone are a pretty bad hack in bash-it because bash does not have native hookups for that.

[romkatv]

Let's put it like this: I stripped down the number of plugins and prompt components I use and together with gitstatusd it is now blazing fast.

Oh, that's nice!

I personally would switch to zsh anyway, but especially at work this is not an option, as too much proprietary 3rd party tools rely on the presence of a csh or bash.

Do these tools assume that your shell is bash, or do they come with scripts with #!/bin/bash at the top? If the latter, this isn't a problem -- you can execute bash scripts from zsh the same way you can execute zsh (or python, or perl, or ...) scripts from bash.

[markusdd]

No generally these are env scripts for RTL simulators and the like, which need to be sourced for these dumb tools to work properly. And usually all you get is a .csh and a .sh file. At least Cadence is now moving away from that stuff so that setting PATH is enough to actually run a tool, but still it's usually a pain. In hardware design you have some of the most expensive tools the world has to offer, yet they are some of the worst in terms of usability because they maintain backward compatibility into the 80's...

[romkatv]

No generally these are env scripts for RTL simulators and the like, which need to be sourced for these dumb tools to work properly. And usually all you get is a .csh and a .sh file.

Ouch 😁

FWIW, zsh has emulate builtin, which you can call as in emulate sh, emulate csh, etc. It makes it almost compatible with other shells. The nice thing is that you can switch back and forth temporarily. E.g., you can source a script with emulate csh in effect and then wrap all functions that were created in emulate -L csh so that these functions are executed with csh rules. I'm not saying it'll totally work or that you should do it, but it's something that is occasionally helpful when using zsh and it doesn't exist in other shells. zsh can also use bash completions -- no problems there.

[markusdd]

yep, looked at that before. But then there is also that problem of legacy in own tooling and collagues who probably would not want to deal with that. And we spent a great deal of effort to unify the shell environment so that everyone works with the same stuff reproducibly. I think you know the issues, inconsistent tool versions etc. can create all kinds of nasty problems.

Anyway, thanks very much for your contribution here and over at the PR, that was some very efficient afternoon :D