Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incompatible with bash_completion from Homebrew #1

Open
jelder opened this issue Aug 12, 2012 · 4 comments · May be fixed by #8
Open

Incompatible with bash_completion from Homebrew #1

jelder opened this issue Aug 12, 2012 · 4 comments · May be fixed by #8

Comments

@jelder
Copy link

jelder commented Aug 12, 2012

This line in .bashrc_once causes new shells to hang.

if [ -x /usr/local/bin/brew ]; then
  export PATH="$(brew --prefix coreutils)/libexec/gnubin:$PATH"
  if [ -f `brew --prefix`/etc/bash_completion ]; then
    . `brew --prefix`/etc/bash_completion
  fi
fi
@josephwecker
Copy link
Owner

The most recent commit, d0bfcb8, may have fixed this. If not, also try removing the symlink from ~/.profile . I should have a chance to test directly a little later.

@josephwecker
Copy link
Owner

Can't replicate this. But I don't know what your "brew --prefix/etc/bash_completion" is referring to - I tried various brew and random bash_completions I have on my system but didn't replicate the problem. Let me know if you have more info or if the latest version fixes anything.

@mhmurray
Copy link

The problem is that the .bashrc_once (or .bashrc_all or .bashrc_script) might spawn another bash process. It has nothing to do with Homebrew. When the second bash is spawned, it runs all the .bashrc_* again, but slips past your PID recursion protection. Try the following:

Use a simple script, ~/simplescript

#!/bin/bash
echo "Running script!"
exit 1

In .bashrc_once, add a call to this script
.bashrc_once:

~/simplescript

Now start a new bash session, or run any bash script. It should recursively spawn bash processes (look with "ps a") each with a different PID, of course.

I think you can fix this by changing when you set the guard on the .bashrc_once invocation. Replace this:

[ -f "${PRF}bashrc_once"  ]       && [ -z "$BRCD_RANONCE" ] && . "${PRF}bashrc_once"  && export BRCD_RANONCE=true

with this

[ -f "${PRF}bashrc_once"  ]       && [ -z "$BRCD_RANONCE" ] && export BRCD_RANONCE=true && . "${PRF}bashrc_once"

I don't think there should be a problem with this. If "export BRCD_RANONCE=true" fails, then bashrc_once will never be called, but maybe you've got bigger problems at that point.

Thanks for the hard work on this bash_dispatch tool! I love it.

@mhmurray
Copy link

Update. I don't think it's correct to have the environment variable "run-once" guards in the && chain. I replaced this:

[ -f "${PRF}bashrc_once"  ]       && [ -z "$BRCD_RANONCE" ] && export BRCD_RANONCE=true && . "${PRF}bashrc_once"

with this:

if [ -f "${PRF}bashrc_once"  ] && [ -z "$BRCD_RANONCE" ]; then
  export BRCD_RANONCE=true
  . "${PRF}bashrc_once"
  unset BRCD_RANONCE
fi

As I mentioned in the previous comment, you need to set BRCD_RANONCE before sourcing bashrc_once to avoid recursive calls if bashrc_once invokes a bash script. In addition, you don't want them to be all &&'ed together. This is because the bashrc_once statement could fail for whatever reason. If it does, then the environment variable BRCD_RANONCE will remain set.

joaocc added a commit to joaocc/bashrc_dispatch that referenced this issue Dec 14, 2020
@gaelicWizard gaelicWizard linked a pull request Jul 29, 2021 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants