-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
NT escaping in shebang in easy_install #188
Comments
Original comment by t3kcit (Bitbucket: t3kcit, GitHub: Unknown): Sorry I was not logged in :-/ |
Original comment by guyroz (Bitbucket: guyroz, GitHub: Unknown): well, escaping doesn't work either:
|
Original comment by guyroz (Bitbucket: guyroz, GitHub: Unknown): you should avoid directories with spaces on unix systems, this won't be the only incompatibility problem you'll run into. |
Original comment by guyroz (Bitbucket: guyroz, GitHub: Unknown): escaping does not work either; I don't know of a solution to white-spaces in shebang lines on Unix. if there is one, re-open and we'll see how to implement it. but from a quick search spaces are not supported in shebangs (again, on Unix). |
Original comment by jaraco (Bitbucket: jaraco, GitHub: jaraco): Indeed, I wrote a blog about how Unix doesn't support spaces in filenames. You may be right that skipping the quoting behavior (and just raising an error) would be better on Unix systems. |
Original comment by guyroz (Bitbucket: guyroz, GitHub: Unknown): yes, of-course, I was referring to Unix; modified my comment so it'll be clear |
Original comment by jaraco (Bitbucket: jaraco, GitHub: jaraco): Reading through the source, it appears to me as if "executable" is allowed to be supplied, but options to that executable should be present as options to the original script text. What this ticket is requesting is that "executable" be interpreted to allow multiple entities on Unix and be considered to be a single entity on Windows. That would be a bad choice. @t3kcit would it be possible in your use case to instead pass a script with something like script_text="#!/usr/bin/env script param", executable="/usr/bin/env" ? The way I read the code, the 'script' and 'param' would be included in the resulting script and /usr/bin/env would be replaced by /usr/bin/env and there wouldn't be any quoted characters. Let me know what you find. |
Original comment by guyroz (Bitbucket: guyroz, GitHub: Unknown): @t3kcit could you describe in more details what is your use-case? what are you trying to replace and with what? |
Original comment by t3kcit (Bitbucket: t3kcit, GitHub: Unknown): Thanks a lot for your replies and sorry for being unclear. I think Jason got it right. I basically want to pass parameters to the shebang executable. Thanks a lot! Andy |
Original comment by jaraco (Bitbucket: jaraco, GitHub: jaraco): When I mention 'script_text', I'm referring to the parameter to the get_script_header function. It's hard to infer from the description how you're using that call, but because you referenced it explicitly, I'm presuming you're calling that function directly or you've at least traced the behavior in your usage to that function call. @t3kcit can you provide a description of what you're trying to accomplish (i.e. what are your inputs)? |
Original comment by t3kcit (Bitbucket: t3kcit, GitHub: Unknown): Sorry to be unclear. I use (or want to use) something like the below:
in the call to setuptools setup function. This ends up in the function "get_script_header" function, where it is escaped. |
Original comment by t3kcit (Bitbucket: t3kcit, GitHub: Unknown): I would prefer not to change the scripts if possible. I have to do this to a lot of packages and limiting my changes to the setup.py script will hopefully make it easier to maintain forks. |
Original comment by jaraco (Bitbucket: jaraco, GitHub: jaraco): That clarifies things. So it seems that the issue is that you want to provide "options" (a.k.a. parameters) to the executable and simply passing those options as the executable is causing them to be escaped (as one might expect). In any case, setuptools can probably support "executable" meaning more than simply an executable. |
Original comment by t3kcit (Bitbucket: t3kcit, GitHub: Unknown): Sorry for being unclear in the beginning. |
Original comment by wojdyr (Bitbucket: wojdyr, GitHub: wojdyr): I think I have the same problem, but I'd put it differently. For example, if I have in
distutils will, as expected, change shebang in scripts to:
but setuptools will start script with:
Could it be changed just for the sake of consistency? |
Original comment by t3kcit (Bitbucket: t3kcit, GitHub: Unknown): Another good point. I really don't see any reason for this call, as it clearly breaks things, but does not seem to have an beneficial effect on any platform. |
Original comment by jaraco (Bitbucket: jaraco, GitHub: jaraco): I believe I have a fix for this. In the latest commits, I've updated Setuptools to allow for the build_scripts parameter to be a CommandSpec instance, which allows specifying the command line entities explicitly:
I quickly realized that this verbose syntax isn't particularly friendly, so I allowed it to also accept just a simple list:
I then realized that still won't fix the situation where the executable is specified in a metadata file (such as pydistutils.cfg), so I made a backward-incompatible change which treats the executable if it's a string as a command line, requiring quoting or escaping if spaces are expected in the path. So now the syntax should be exactly as users have expected:
I haven't made a release, but do please download and install the latest source and report your experience with this change. |
Original comment by t3kcit (Bitbucket: t3kcit, GitHub: Unknown): Thank you for the fix. |
Original comment by joeyespo (Bitbucket: joeyespo, GitHub: joeyespo): I think this fix broke something else. I have Python installed in I noticed that older console_scripts were working, and turns out it's because they were quoted.
Adding quotes around the newly installed scripts fixes it. Any suggestions? Should I open a new issue? Thanks. |
Originally reported by: Anonymous
Hi.
As far as I can see, there is still escaping of spaces in the shebang in the current version:
https://bitbucket.org/pypa/setuptools/src/0e53d50b76aabfdee7b6166593e41d41a16e6a25/setuptools/command/easy_install.py?at=default#cl-1546
I find this quite unfortunate, as this is of very limited use, but prevents some valid use cases.
The current code quotes all shebang strings that contain spaces. On all POSIX systems that I tried (current Ubuntu, ancient redhat, current OS X) this is illegal and simply doesn't work. Given the name of the function, it seems this was intended for windows NT (?).
However, this escaping prevents valid use cases, for example it doesn't allow the specification of "/bin/env /bin/python". I think there is a workaround for this specific case. However I have a use case where I need a different command to produce the correct python executable. This would be easy, except for the escaping.
If it is possible to detect being on a posix platform (probably not that easy?), we could just skip the escaping, as it is never beneficial. If this is not possible, maybe just skip the escaping all together? The benefit seems very platform specific.
Thanks,
Andy
The text was updated successfully, but these errors were encountered: