GeezerVison is showing github.com — venv activate bash script has wrong line endings in Windows · Issue #76632 · python/cpython
venv activate bash script has wrong line endings in Windows #76632Description
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = None
created_at = <Date 2017-12-30.04:13:49.296>
labels = ['3.10', 'type-bug', '3.8', '3.9', 'OS-windows']
title = 'venv activate bash script has wrong line endings in Windows'
updated_at = <Date 2021-03-17.19:57:39.007>
user = 'https://bugs.python.org/Kevin' bugs.python.org fields:
activity = <Date 2021-03-17.19:57:39.007>
actor = 'eryksun'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Windows']
creation = <Date 2017-12-30.04:13:49.296>
creator = 'Kevin'
dependencies = []
files = []
hgrepos = []
issue_num = 32451
keywords = []
message_count = 8.0
messages = ['309215', '309258', '339985', '340038', '340052', '340065', '340272', '388962']
nosy_count = 9.0
nosy_names = ['paul.moore', 'tim.golden', 'r.david.murray', 'erik.bray', 'zach.ware', 'eryksun', 'steve.dower', 'Kevin', 'astanton1978']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue32451'
versions = ['Python 3.8', 'Python 3.9', 'Python 3.10'] ActivityKevin commented on Dec 30, 2017 MannequinAuthor More actions attempts from within cygwin:
- The Posix way:
$ python -m venv taco
$ cd taco
$ source bin/activate
-bash: $'\r': command not found
-bash: Scripts/activate: line 4: syntax error near unexpected token `$'{\r''
'bash: Scripts/activate: line 4: `deactivate () {
- The windows way:
$ python -m venv taco
$ cd taco
$ /full/path/to/venv/taco/scripts/activate.bat
$
- the only solution from cygwin (still not 100% functional):
$ python -m venv taco
$ cd taco
$ cd Scripts
$ cmd
C:\taco\Scripts\> activate.bat (taco) C:\taco\Scripts\>
HOWEVER. when running "pip freeze" in number 3 it returns the system packages despite the "include-system-site-packages = False" in pyvenv.cfg
When #3 is run inside command prompt "pip freeze" returns nothing correctly.
Come on guys, please don't make me use command prompt or powershell. bitdancer commented on Dec 30, 2017 cygwin in not currently fully supported (there are people working on it, though). Can you determine if this is a bug in cygwin's bash support, or something else? It certainly works with bash shell on unix. I would presume that from cygwin one would want the posix way to work, and that it should be possible. StingyJack commented on Apr 11, 2019 I dont think this is a Cygwin only problem, as this is happening to me when running WSL (Windows subsystem for Linux). I can run Scripts\Activate.ps1 from powershell, Scripts\activate.bat from cmd, but running scripts/activate from wsl reports this same error. eryksun commented on Apr 12, 2019 Why is the bash/zsh "activate" script getting distributed with CRLF line endings? Apparently Windows builds of bash (e.g. git-bash) can handle CRLF line endings, but Cygwin bash cannot.
As to Linux bash in WSL, the activate script from a virtual environment created by Windows Python can't be used anyway. It modifies $PATH using a DOS path like "C:\taco" as opposed to a WSL path like "/mnt/c/taco".
when running "pip freeze" in number 3 it returns the system
packages despite the "include-system-site-packages = False"
in pyvenv.cfg
The 3rd attempt is just running activate.bat from a CMD shell. That should work, unless you exit out of CMD back to bash. Anyway, check where.exe pip after activating. It should find "C:\taco\Scripts\pip.exe" first. zooba commented on Apr 12, 2019 It probably just needs a gitattributes fix so it doesn't get converted when cloned to make the release build.
This is assuming that in all these cases people are installing Python for Windows and trying to use it from a non-Windows shell (both WSL and Cygwin have their own "native" Python builds that presumably work). I can't tell if there's something else going on here. eryksun commented on Apr 12, 2019
This is assuming that in all these cases people are installing Python
for Windows and trying to use it from a non-Windows shell (both WSL
and Cygwin have their own "native" Python builds that presumably
work).
It should work from Cygwin and MSYS2 since they support DOS paths in $PATH. I don't have Cygwin installed, but I tried MSYS2 bash and Git bash, and it worked fine, even with CRLF line endings. Apparently only Cygwin bash has a problem with CRLF line endings.
The issue with using Windows Python in this case is that the terminals for these environments emulate Unix PTYs with named pipes (e.g. "msys-0123456789abcdef-pty0-from-master" for stdin and "msys-0123456789abcdef-pty0-to-master" for stdout and stderr). Thus isatty() is false, and interactive mode has to be forced with the -i command-line option. embray commented on Apr 15, 2019 Coincidentally I just encountered this myself when trying to activate a venv created by Python for Windows while in a Cygwin shell. Indeed, bash for Cygwin is just like bash anywhere else, and considers it a syntax error to encounter unexpected CR's.
Alas, venv creates <path>/<to/<env>/Scripts/activate with CRLFs. After running dos2unix on it, this script can be sourced from Cygwin and otherwise works fine.
The issue that arises with interactive mode is a known issue not specific to Python or venv. It can also be worked around by running python with winpty. eryksun commented on Mar 17, 2021 changed the title [-]python -m venv activation issue when using cygwin on windows[/-] [+]venv activate bash script has wrong line endings in Windows[/+] on Mar 17, 2021daytonb commented on Apr 21, 2023 I was going to fix this issue, because I just ran into it this week while helping a co-worker. However, it's already been fixed in main 😃.
The need to adjust .gitattributes was noted in issue #103088 and closed by merge request #103591, so this issue can be closed now.
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|