-
-
Notifications
You must be signed in to change notification settings - Fork 3.1k
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
pyenv init getting into an infinite loop when invoked from bashrc #264
Comments
It is pretty weird. I couldn't reproduce such strange behaviour at least on Debian/Ubuntu/OS X. The http://www.gnu.org/software/bash/manual/html_node/Bash-Startup-Files.html The followings are my answers:
|
|
I confirmed that this doesn't reproduce with out-of-box Debian/Ubuntu. I created a Docker container for reproduction, but the % docker run -it yyuu/pyenv:issue264 bash -l
this is .bashrc
this is .profile
root@ddbcabcb80ef:/# I am wondering if I should fix this in This is the FROM ubuntu:14.04
MAINTAINER Yamashita, Yuu <peek824545201@gmail.com>
ENV PATH /root/.pyenv/shims:/root/.pyenv/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin
ENV DEBIAN_FRONTEND noninteractive
RUN apt-get --quiet --yes update
RUN apt-get --quiet --yes upgrade
RUN apt-get --quiet --yes install build-essential curl git libbz2-dev libreadline-dev libsqlite3-dev libssl-dev patch zlib1g-dev
RUN git clone --quiet https://github.com/yyuu/pyenv.git /root/.pyenv
RUN cd /root/.pyenv && git reset --hard 35aed21
RUN echo 'export BASH_ENV="/root/.bashrc"' >> /etc/profile
RUN echo 'echo "this is .profile"' >> /root/.profile
RUN echo 'echo "this is .bashrc"' >> /root/.bashrc
RUN echo 'eval "$(pyenv init -)"' >> /root/.bashrc
## Enable infinite loop
#RUN sed -i.orig -e '/^\[ -z "\$PS1" \]/s/^/#/' /root/.bashrc |
As I mentioned, I encountered this in CentOS rather than Debian. Apparently Debian/Ubuntu has the concept of only having .bashrc which has a hard-coded check for non-interactive shell in the beginning, whereas CentOS/RedHat has both a .bash_profile (which is run for login shells) and a .bashrc (which is meant to be run for non-interactive shells). In particular bash_profile sets BASH_ENV to point to .bashrc. The most easy way to reproduce the infinite loop is to change the line
to
in your Dockerfile, and then, for example, invoke pyenv. Yes, I think that this should be mentioned in the docs somewhere next to the installation instructions that require adding $(pyenv init -) to the startup script. |
山下 優 (やました ゆう) |
Adding warning in README has already been merged. |
Might be of value to others, but I conditionally initialized pyenv to avoid this problem. if [ -n "$(type -t pyenv)" ] && [ "$(type -t pyenv)" = function ]; then
# echo "pyenv is already initialized"
true
else
if which pyenv > /dev/null; then eval "$(pyenv init -)"; fi
if which pyenv-virtualenv-init > /dev/null; then eval "$(pyenv virtualenv-init -)"; fi
fi |
@StevenACoffman's solution didn't quite work for me on zsh, so I implemented a workaround using environment variables here:
|
A little late to the party, but a more idiomatic fix I'm using is: [-z "$PS1" ] && return
eval "$(pyenv init -)"
eval "$(pyenv virtualenv-init -)" Line 1 prevents the file from being processed any further if we're executing non-interactively (ie. triggering bash via the pyenv framework itself). This is the method used by many default |
Slight issue with the first line, it should be:
instead (with a space between the |
If, like me, you're on a bash from Debian Buster or newer and have never even heard of the above BASH_ENV weirdness, let alone used it, then maybe you too have been bitten by bash's attempt to determine whether it's been run under an
That'd be harmless, wouldn't it? The recommendation that was made in the pyenv documentation under this, ahem, long Closed issue, on the other hand, recommends something that isn't going to work for the invocation I'm seeing, from Jenkins rather than ssh. I can't be forking pyenv-init locally. What happens when you
Oh, just what we want. That's OK then. I'd rather limit the behavior to the pyenv part of
... and hope someone takes pity on me, reopens this and makes pyenv-init cope with bash's weirdness... or changes the documentation. |
Doh, that
|
The current installation instructions suggest to place the line
eval "$(pyenv init -)"
at the end of .bash_profile or .bashrc depending on the Linux flavor.
This suggestion may lead to the following scenario:
Obviously, the immediate fix for the problem is to put the initialization line into .bash_profile rather than .bashrc, however at the point in time, when the user encounters this error, this is far from obvious (in particular, this has been the reason for me to not start using pyenv the first time I tried it and had no time to debug the problem, and now it took quite some time to figure out what's happening).
It would be great to find some nice way to prevent this possibility for an infinite loop somehow. The options I'd see, in order of niceness:
The text was updated successfully, but these errors were encountered: