You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
venv activate bash script has wrong line endings in Windows #76632
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.
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
StingyJackmannequin
Mannequin
More actions
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.
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.
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.
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.
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.
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, 2021
Activity
Kevin commentedon Dec 30, 2017
attempts from within cygwin:
$ python -m venv taco $ cd taco $ /full/path/to/venv/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 commentedon 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 commentedon 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 commentedon 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".
The 3rd attempt is just running activate.bat from a CMD shell. That should work, unless you
exitout of CMD back to bash. Anyway, checkwhere.exe pipafter activating. It should find "C:\taco\Scripts\pip.exe" first.zooba commentedon 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 commentedon Apr 12, 2019
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
-icommand-line option.embray commentedon 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 commentedon Mar 17, 2021
The POSIX "Lib/venv/scripts/common/activate" script needs a line-ending exception in ".gitattributes":
https://github.com/python/cpython/blob/master/.gitattributes
[-]python -m venv activation issue when using cygwin on windows[/-][+]venv activate bash script has wrong line endings in Windows[/+]daytonb commentedon 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.