attempts from within cygwin:

1. 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 () {

2. The windows way:

$ python -m venv taco
$ cd taco
$ /full/path/to/venv/taco/scripts/activate.bat
$


3. 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.

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.

The POSIX "Lib/venv/scripts/common/activate" script needs a line-ending exception in ".gitattributes":

https://github.com/python/cpython/blob/master/.gitattributes