I have a script called "submit.py" and it begins with "#!/usr/bin/env python.exe" which works if I'm inside the directory containing "submit.py". I can run "./submit.py" and the script runs properly. I decided to add the directory containing "submit.py" to my PATH environment variable so I can run "submit.py" from any directory.
However, I cannot run "submit.py" from any directory. The error I get is:
D:\Program Files\Python36\python.exe: can't open file '/mnt/d/Program Files/kattisTools/submitToKattis': [Errno 2] No such file or directory
I believe the error has to do with the differences in how Windows Python expects a path to be and how WSL handles paths. What I mean is python.exe should be looking for "D:\Program Files\kattisTools\submitToKattis" but WSL is feeding it "/mnt/d/Program Files/kattisTools/submitToKattis"
I also believe that "./submit.py" works when I'm inside the directory containing submit.py because the '.' operator is handled differently in WSL that feeds the real Windows path to Windows Python.
I was hoping there's a remedy so that I can run "submit.py" from any directory with it relying on Windows Python?
06/26/2018 Update: I have looked into Shared Environment Variables between WSL and Windows, and particularly the '/w' flag. I haven't gotten this to work the way I wanted yet but it might be something?
did you get this to work by now?
Having the same issue here when calling a python script with a pipenv virtual environment (windows based python.exe) from within the wsl :(
You are completely right....
Calling the script directly from its folder it looks like that:
C:\scripts\.venv\Scripts\python.exe ./test.py
and it works
while it looks like that (and does not work) if it is called from another folder:
C:\scripts\.venv\Scripts\python.exe /mnt/c/scripts/test.py
Related
I have been using Jenkins for a few years and recently bought a new Windows 10 PC. I installed Jenkins 2.89.2, Visual Studio 2017 and Python 3.6 and copied several Jenkins jobs from my previous Windows 7 PC.
The problem that I encountered was that all the python scripts in the free-style Jenkins jobs now do nothing.
I have similar command-line batch files which run these python scripts which work just fine in a command window on the new PC.
I have also checked the file associations with ftype, and ended up changing it:
ftype Python.File
Python.File="D:\Python36_64\python.exe" "%L" %*
My work-around is like this:
Example line which worked under Windows 7:
CreateBuildNumber.py <= uses PATH to find this file, then file associations to run python
Replacement line need to work under Windows 10:
python .\Scripts\CreateBuildNumber.py <= uses PATH to find python.
How can I avoid explicit paths in my scripts?
Update:
D:\project>assoc | findstr -i python
.py=Python.File
.pyc=Python.CompiledFile
.pyd=Python.Extension
.pyo=Python.CompiledFile
.pyw=Python.NoConFile
.pyz=Python.ArchiveFile
.pyzw=Python.NoConArchiveFile
echo %PATH%
D:\Python36_64;D:\Python36_64\Scripts;.\Scripts;"C:\Program Files\CppCheck";C:\windows\system32
Further Info
I removed .\Scripts from the %PATH% and re-ran the job, having also moved demo.py into .\Scripts, now instead of doing nothing there is the error:
'demo.py' is not recognized as an internal or external command, operable program or batch file.
This means that Windows IS looking for and finding python scripts, but is failing to execute them. Why would windows not take the next step and use file associations to find an executable program to run, taking the file as a parameter?
Update:
Now everything works as it should and I don't know why.
I recently started using a different job on Jenkins that I had neither run nor touched for over two years and that one just worked without modification. I have since gone back over the job in question and reverted all the changes and this one works as well.
My guess is that Windows 10 has been patched.
The fact that "demo.py" gives the message '...is not recognized as an internal or external command' doesn't convince me that your script is recognized as executable. If I type 'turkey.abc' into a command prompt window I get the same error, and I don't have a tool for executing '.abc' files.
I see two possibilities here:
1) In batch scripts, executable extensions sometimes must appear in an environment variable called PATHEXT.
In the Jenkins batch script, add a "set" command near the top of the script to dump the environment variables for your running script into your Jenkins build log (you can remove the set command after this is debugged). Run the build. Look not only for the definition of PATH, but also at PATHEXT. Is ".py" one of the extensions listed there?
I have experienced this problem with Perl scripts. However, I'm wimping out on claiming this definitely since in testing on my Windows 10 home PC I am successfully executing .py scripts even without it being in PATHEXT, so it's something to try but it may not be this.
2) Another possibility is that the environment in which your service is running is different than the environment you get when you open a command prompt on your desktop (because the Jenkins service runs as a different user than the one you log in as.)
Adding "set" to your Jenkins batch commands will help debugging this too, since it will show you the environment your Jenkins script is running in. Then you can examine PATH to see if your script folder is being found.
It is also possible that the file associations for Python were installed for your user only, not for all users (i.e., in HKEY_CURRENT_USER in the registry instead of HKEY_LOCAL_MACHINE). That is harder to dump into your Jenkins log - the 'reg' command would do it, but it will take you a number of tries to get everything you need. You might be able to figure it out by just examining the registry. Search for ".py" - if it occurs in HKEY_LOCAL_MACHINE that is not it; if it occurs in HKEY_CURRENT_USER that is at least part of the problem.
I don't know if this will fix your issue but you shouldn't have a relative path in your PATH environment variable.
Can you try again after having removing .\Scripts from the PATH variable? (don't forget to open a fresh new terminal do get the new %PATH% value)
The problem is that your PATH variable doesn't include the paths of you python scripts. You need the full path of the Scripts directory. Not the relative path .\Scripts.
I have a python executable I wish to run from PowerShell using the command python [executable].py.
First I changed the directory in PowerShell to the location of the executable using cd path\to\my\directory which worked fine. However whenever I tried to use python to execute my code, PowerShell immediately searches for the [executable].py in Python's installation folder - fails to find it - and gives the an error that it cannot find the appropriate file.
How do I make sure that Powershell looks for the executable in the directory I indicated as opposed to the default Python installation folder?
If you want to run python.exe from a location other than the installation directory you'd call it with its full path:
& 'C:\path\to\python.exe' 'your.py'
If you want to run it from the current directory, prepend the filename with the relative path .\:
& .\python.exe 'your.py'
If you call an executable without a path like this:
& python.exe 'your.py'
PowerShell will look for a matching file in the directories listed in the $env:PATH environment variable, and execute the first match (or report an error if no matching file can be found).
With that said, the error you got in your screenshot is not because of the Python interpreter, but because of the file you want the interpreter to run. You're calling
python conditions
when you actually want to run
python conditions.py
Neither PowerShell nor Python magically add the extension for you. Instead they report an error because a file conditions (without an extension) simply doesn't exist.
I have a Python script that I would like to be able to execute from no matter where. Either in Linux or in Windows, but in this case preferably in Windows. Putting the path to the script into PATH under Windows did not work, so from some directory calling python my_script.py results in the message that there is no such file in this directory. So, is this somehow possible?
You can try creating an alias as such:
Linux
Create a .bash_aliases file on your home folder
Add an alias such as alias pscript='python /home/pythonscript.py'
Log out and back in or do a source .bash_aliases
Windows
Run doskey pscript=python C:\script.py. Read more here
The PATH is used to search for executables, and this doesn't include in windows script files.
A workaround is to convert the script to a batch file, see here
how to simply have the script act also as a batch file
For the operating system to run your script, it needs to find it (the PATH variable), recognize that it is executable and know which program should execute it. You seem to have the PATH part handled, so now for the other two.
On unixy systems you need to make the script executable. To set the user-executable bit, do chmod u+x myscript.py. Then you need to tell the system which program should run it. Typically you use the "shebang" as the very first line in the file:
#!/usr/bin/env python3
The system will search the path for a program called "python3" (use "python" for python 2 scripts) and use that executable to run the script.
On Windows, you need to associate the file extension (.py) with the python exeuctable. That's usually done for you when python is installed. If not, you can dig into ftype, assoc and pathext here.
Windows doesn't care about the shebang (unless you are running cygwin, then see unixy systems above) so the same script can live in both worlds.
Once the script is executable, you call it directly instead of executing python and giving the file as the script name. Its just
myscript.py
I've been trying to figure this out for more than 2 days, screening the internet and the tutorial, but yet I don't have solved my problem. I'm a real newb and don't yet really know what I'm doing..
Software I use:
Mac OS X 10.6
Python v3.2.2
Interactive interpreter (IDLE)
Problem:
IDLE's default directory is /Users/ME/Documents/. Files with the extention .py can only be opened when located in this directory. However, I made a folder where I would like to save all the .py files etc that have to do with this software. Currently, IDLE cannot load .py files from the chosen directory by me.
What I did first was I added to IDLE:
import sys.
sys.path.append('Users/Mydir/')
sys.path
However, in an already existing thread from 2010 I read sys.path is for the Interpreter ONLY, and that if I am to change this I need to modify the PYTHONPATH environment variable:
PYTHONPATH="/Me/Documents/mydir:$PYTHONPATH"
export PYTHONPATH
However, I'm confused how to use this and cannot find answers to my following questions:
1) PYTHONPATH (.py?) is already existing on my computer when I installed the program?
If YES, where is it? I cannot find it anywhere.
If NO, I need to create one. But where and what should be the content so that IDLE can load files from a non-default directory? Should it contain only the words in bold?
I hope I made my problem clear.
Cheers
It's not totally clear to me what you mean by load. That could mean Open and Close files in the IDLE editor. Or it could mean being able to use the Python import statement to load existing Python modules from other files. I'll assume the latter, that by load you mean import.
There are two general ways to launch IDLE on Mac OS X. One is from the command line of a terminal session; if you installed Python 3.2 using the python.org installers, by default typing /usr/local/bin/idle3.2 will work. The other way is by launching IDLE.app from /Applications/Python 3.2, i.e. by double-clicking its icon. Because you say the default directory for files is your Documents folder, I'm assuming you are using the second method because IDLE.app sets Documents as its current working directory, which becomes the default directory for *Open*s and *Save*s and is automatically added as the first directory on Python's sys.path, the list of directories that Python uses to search for modules when importing.
If you want to add other directories to sys.path, as you've noted you can use the PYTHONPATH environment variable to do so. The standard way to do this is to add an export PYTHONPATH=... definition to a shell startup script, like .bash_profile. However, if you use IDLE.app, no shell is involved so commands in .bash_profile have no effect.
While there are ways to modify the environment variables for OS X GUI apps, in this case, a simpler solution is to use the other method to invoke IDLE, from the command line of a shell session, using either /usr/local/bin/idle3.2 or, if you've run the Update Shell Profile command in the /Applications/Python 3.2 folder (and opened a new terminal session), just idle3. Then, a PYTHONPATH environment variable you set up will be inherited by that IDLE.
BTW, there is no direct way to modify the initial current working directory of IDLE.app from Documents other than modifying the code in IDLE. If you start IDLE from a command
line, it inherits the current working directory of the shell.
[UPDATE] But rather than fooling around with defining PYTHONPATH, here is another even simpler, and probably better, approach that should work with either IDLE.app or the command line idle. It takes advantage of Python path configuration (.pth) files and user site-package directories. Assuming you are using a standard Python framework build of 3.2 (like from a python.org installer) on Mac OS X, create a path file for the directory you want to permanently add to sys.path. In a terminal session:
mkdir -p ~/Library/Python/3.2/lib/python/site-packages
cd ~/Library/Python/3.2/lib/python/site-packages
cat >my_paths.pth <<EOF
/Users/YOUR_USER_NAME/path/to/your_additional_python_directory_1
/Users/YOUR_USER_NAME/path/to/your_additional_python_directory_2
EOF
Now, whenever you run that Python 3.2 or IDLE under your user name, the directories you have added to the .pth file will automatically be added to sys.path.
BTW, the exact path location of the user site-packages directory for versions of Python earlier than 3.2 or 2.7 may be slightly different. Also, on other Unix-y systems, the default location for the user site-package directory is ~/.local/lib/python3.2/site-packages.
PYTHONPATH is an environment variable (see here and here). I don't have a Mac, but from the threads I have linked to you would type something like
launchctl setenv PYTHONPATH=/Me/Documents/mydir:$PYTHONPATH
on the command line to allow you to run Python scripts from /Me/Documents/mydir. Alternatively, put this line in a file called .bashrc in your home directory (~) and this path will be set each time each time you open a terminal. See here for a short introduction to .bashrc and other .bash* files. Hope that helps.
EDIT See also this question.
When attempting to run .py files from the command prompt I get this,
C:\users\ocean>python helloworld.py
python: can't open file 'helloworld.py': [Errno 2] No such file or directory
The environment variables are already set to ;C\python27 and ;C\python32 (yes, I'm running both releases of python.)
Do I have to set a new variable? What must I do? Running Windows 7, it was a pain to get it to even run that error, before 'python' wasn't even recognized.
Edit: C:\users\oceans does not include my python folder. Is there anyway to redirect the directory so that I won't have to move all of the python files to ocean?
You have to either do:
python c:\path\to\the\file.py
or
cd c:\path\to\the
python file.py