Whitespace in root path of virtualenv breaks scripts #53

Open
vbabiy opened this Issue Mar 14, 2011 · 16 comments
@vbabiy

I'm not really sure if this is a distribute/setuptools/virtualenv but,

If I install virtualenv in

/var/lib/hudson/home/jobs/Minification WebHelpers/workspace/python/2.4

then run ./bin/easy_install:

bash: ./bin/easy_install: "/var/lib/hudson/home/jobs/Minification: bad interpreter: No such file or directory

Seems like something does not obey whitespace in path names correctly.


@rguldener

+1, confirmed with Mac OS X 10.7.3 and Python 2.7.1

Kind of annoying, would be great to have a fix

@chaoflow

We are able to create a virtualenv with spaces in the name (see #278), but easy_install and pip stumble over it later:

% virtualenv "foo bar"
New python executable in foo bar/bin/python
Installing setuptools............done.
Installing pip...............done.
% ./foo\ bar/bin/easy_install nose
zsh: ./foo bar/bin/easy_install: bad interpreter: "/tmp/cfl/foo: no such file or directory
127 % ./foo\ bar/bin/pip install nose 
zsh: ./foo bar/bin/pip: bad interpreter: "/tmp/cfl/foo: no such file or directory
@mattvh

I'm also here to confirm that this is an issue with OS X (10.8 here). If you edit the VIRTUAL_ENV variable and shebangs in bin you can get it to work, but a fresh env chokes on any spaces in a path. Which is a big problem for OS X, given that the boot drive is typically named "Macintosh HD," so every path starts with "/Volumes/Macintosh HD..."

The hack I'm using works as follows.

bin/activate:

VIRTUAL_ENV='/Volumes/Macintosh\ HD/path/to/my/project'

bin/pip and bin/easy_install:

#!"/Volumes/Macintosh\ HD/path/to/my/project/venv/bin/python"

Pip seems to be working after escaping the space in the path.

@zakdances

Why was this closed? It's still very much an issue. edit my mistake, it's still open

@qwcode

this issue still shows open.

@1mentat

I was able to get around this my creating a symbolic link from my home directory to the one I was wanting to work in (that otherwise had a space in it).

@michealbeatty

I'm seeing this too because Mac. I get around this by manually editing the shebang line in the scripts to !#/usr/bin/env python and all works. However, as others have mentioned, this has to be done with each new env and any additional scripts installed in the env.
Seems this should be an easy fix in the code to either escape the space or use /usr/bin/env if is_darwin. However since I'm pretty much a noob at this I could be wrong.

@Ivoz
Python Packaging Authority member

This isn't just for mac, it's basically part of the specification/behaviour of *nix systems.

You can't have spaces in the first argument of the shebang line (they will get turned into separate arguments instead), and normally there's no escaping / quoting allowed either.

http://lists.gnu.org/archive/html/bug-bash/2008-05/msg00053.html

@michealbeatty

I know, I ran into this problem with anaconda as well. t's just endemic with Mac because the drive name has the whitespace in it.

@jashephe

It looks like this would be corrected by #611. Has there been any review of the efficacy of that pull request?

@diimdeep

So annoying, should be fixed asap.

@pfmoore
Python Packaging Authority member

See the link @Ivoz posted, this is a Unix limitation. #611 might work for some Unix variants, if they support backslash escapes in a shebang line, but it's not clear which versions do (and the code just blindly does it without checking - which admittedly won't make the problem worse, but won't help either if it's not supported...)

@jashephe

It's indeed true that this is a result of the way that unix handles shebang lines, but if #611 fixes the problem for some systems and doesn't worsen the problem for others, would that still be an improvement?

@pfmoore
Python Packaging Authority member

If that's true then yes. But I can'rt comment on #611 as I'm not a Unix developer. There might be cases where it makes things worse, I just don't know. Sorry I can't be more help.

@jashephe

Fair enough. #611 probably needs to be more carefully looked at and tested for fringe cases.

@acidjunk

Even worse: on windows it breaks on the default Jenkins path with the same error:
FATAL: whitespaces are not allowed in Python interpreter's path: C:\Program Files (x86)\Jenkins\shiningpanda\jobs\c3418983\virtualenvs\d41d8cd9

@davidbstein davidbstein added a commit to davidbstein/virtualenv_decompressed_scripts that referenced this issue Oct 18, 2015
@davidbstein davidbstein escape __VIRTUAL_ENV__ path.
Fixes issue pypa/virtualenv#53 in bash and shell by using the printf %q "shell quote" formatter, which escapes as appropriate for a given environment. Falls back to quoting some characters that universally need to be escaped. Fallback is needed because there are several printf implementations, not all of which are guaranteed to have the %q formatter (though bash always should).
0bc6629
@davidbstein davidbstein added a commit to davidbstein/virtualenv that referenced this issue Oct 18, 2015
@davidbstein davidbstein escape string in __VIRTUAL_ENV__ path for bash
Fixes issue pypa/virtualenv#53 in bash and shell by using the printf %q "shell quote" formatter, which escapes as appropriate for a given environment. Falls back to quoting some characters that universally need to be escaped. Fallback is needed because there are several printf implementations, not all of which are guaranteed to have the %q formatter (though bash always should).

uncompressed diff here: davidbstein/virtualenv_decompressed_scripts@0bc6629
8adca33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment