Issue #143 resolved

No such file or directory

created an issue

Whenever I try to workon any project, I get errors like this.

{{{ $ workon project virtualenvwrapper.user_scripts could not run "/home/username/.virtualenv/preactivate": [Errno 2] No such file or directory }}}

I even created a brand new project, and got a double error!

{{{ $ workon test virtualenvwrapper.user_scripts could not run "/home/username/.virtualenv/preactivate": [Errno 2] No such file or directory virtualenvwrapper.user_scripts could not run "/home/username/.virtualenv/test/bin/preactivate": [Errno 2] No such file or directory }}}

Those files most definitely do exist. It may very well be something wrong with my system, and not with virtualenvwrapper. These errors only appeared suddenly, and I can not correlate their appearance with anything I have done.

I am using virtualenv 1.7.1 2 and virtualenvwraper 3.4 on Ubuntu 12.04 server. They were both working fine, and the errors appearing did not correlate with an upgrade of any package.

I even tried removing the preactivate scripts. They are re-created and the error persists. Permissions on these files are also correct. I haven't even modified these scripts. They are the default blank ones. Activating the virtualenvs without the wrapper works without any error.

Comments (13)

  1. Doug Hellmann repo owner

    Try setting HOOK_VERBOSE_OPTION=-vvvv and trying again, then look at the hook.log file in $WORKON_HOME to see if the traceback there provides more information.

  2. apreche reporter

    Ok, I found the issue. Not sure if it is virtualenv's problem or mine.

    If I try to run preactivate directly from the command line, I get this error:

    bash: /home/apreche/.virtualenv/preactivate: bash: bad interpreter: No such file or directory

    So it seems that the No such file or directory wasn't the preactivate script itself, but the interpreter that it was looking for when it tried to execute.

    So I changed the first line in the preactivate script.




    And now it is working without error.

    It seems like all the virtualenvwrapper hook scripts have this #!bash style of specifying the interpreter, but only the preactivate one actually causes any error to appear.

  3. Doug Hellmann repo owner

    Does it work if you use this formula?

    The preactivate script may be having the issue because the PATH variable is modified as part of activating/deactivating environments.

  4. Doug Hellmann repo owner

    It really doesn't make sense that bash can't find itself.

    If you fix the preactivate script shebang line and include a "which bash" command in the script, what does it report?

  5. Doug Hellmann repo owner
    • changed status to open

    The hook scripts are created with the shebang line set to "os.environ.get('SHELL', '/bin/sh')". So my guess is your "SHELL" variable is set to just "bash" instead of the full path to the executable. Did you set it like that, or is that the way it is set by default?

  6. apreche reporter

    AHAH! That is the solution.

    For a second I thought that bash might be the default, but it is not. Actually I changed my shell in /etc/passwd to be /usr/bin/screen Then in my /.screenrc I set shell bash. Changing the screenrc shell to /bin/bash is the solution.

    In the end it did turn out to be my bad, and not a bug. It just happened that this lazy setting caused a problem in virtualenv and not anywhere else. Sorry about that, but hanks for the help!

  7. Log in to comment