I have a bunch of useful Python3 scripts that I use in different OS environments. They run fine when called from the terminal but I want to run them from both Windows Explorer and OSX Finder. In Windows, that is not an issue as the *.py files get associated with the installed interpreter.
For OSX, I am having some problems. I tried using the shebang line.
#!/usr/bin/python3
But Finder doesn't recognize it as a script. How do I make Finder recognize *.py files as scripts? I am interested in maximum portability with as few OS modifications as possible.
Also I explicitly specified the interpreter location above. It will be in different locations for different OSes. Is there a way to make it multi-OS so that if it doesn't find it in one location, it will try another? Say if I want to run it from one of Ubuntu's GUI File Manager.
EDIT: Here's more info on my use case. I want to go to a new computer and git clone my repo of Python3 scripts and be able to run them from within the GUI file manager with minimal changes to the new computer.
To make the script more portable use #!/usr/bin/env python3 as shebang. Side effect will be that it will run the first python3 interpreter it finds in the $PATH (Unix StackExchange question on that subject)
To run the script from the finder try to chmod the file. i.e.
chmod +x FILE
Found another possibility here: Link to the Blog
Make this the first line of your Python script "#!/usr/bin/env python"
Change the extension of the script file to ".command" i.e. my_python_script.command
In Terminal make the Python script file executable by running "chmod +x my_python_script.command"
Now when you double click the Python script in Finder it will open a terminal window and run.
Alternative I found would be this but it needs system modification: Superuser question
Related
I've scrolled the internet all over and theres no simple, clean explanation for this. How can I open the Python shell, but inside a terminal window such as CMD? I have an application for it, but want to run it inside a terminal, so I can practice Python code inside my IDE like VS code.
If you have a reasonably new version of Python you need to run py.exe (or just py) instead of python.exe, because the real python executable (python.exe) is not in your path environment variable by default, whereas py.exe is in the /windows directory and thus automatically in path.
So to run your script type py yourscript.py from the directory of your script. If you just run py it will start the interactive interpreter.
Look e.g. at https://www.python-course.eu/python3_execute_script.php
Under the title Start a Python script (almost at the beginning)
there is an instruction. Just write from the command prompt:
python,
a space,
and the filename containing your script, with .py extension.
As in each command, press Enter and your script will be executed.
Of course, I assume that you have installed Python on your computer.
If this is not the case, start from installing it.
I have quite a new Python version installed (3.6.5) and start Python
writing just python. Writing just py also does the job, but (IMHO)
it is not necessary.
If you want to start Python interpreter and play around with some
Python commands, write just python and Enter. The interpreter will
start and display its own command prompt (>>>).
I have Python 3.6 and Windows 7.
I am able to successfully start the python interpreter in interactive mode, which I have confirmed by going to cmd, and typing in python, so my computer knows how to find the interpreter.
I am confused however, as to how to access files from the interpreter. For example, I have a file called test.py (yes, I made sure the correct file extension was used).
However, I do not know how to access test.py from the interpreter. Let us say for the sake of argument that the test.py file has been stored in C:\ How then would I access test.py from the interpreter?
The simplest way would be to just do the following in cmd:
C:\path\to\file\test.py
Windows recognizes the file extension and runs it with Python.
Or you can change the directory to where the Python program/script is by using the cd command in the command prompt:
cd C:\path\to\file
Start Python in the terminal and import the script using the import function:
import test
You do not have to specify the .py file extension. The script will only run once per process so you'll need to use the reload function to run it after it's first import.
You can make python run the script from a specific directory:
python C:\path\to\file\test.py
In command prompt you need to navigate to the file location. In your case it is in C:\ drive, so type:
cd C:\
and then proceed to run your program:
python test.py
or you could do it in one line:
python C:\test.py
I may be misunderstanding what you are seeking, but I think what you are asking for is a IDE-like environment where you can load Python scripts, edit, and debug.
You already have IDLE, https://docs.python.org/3.6/library/idle.html, which came with the Python installation.
There are many IDEs available for Python. https://wiki.python.org/moin/IntegratedDevelopmentEnvironments Personally, I like using PyDev on Eclipse.
I have a script (Shell, chmod-ed to 755. Python is in the script, meaning not run from an outside .py file) that is executable. It works when I run it. How can I make a .app that executes said script on runtime? I have a simple .app that has this structure: APPNAME.App>Contents>MacOS>script
This does not run. Is there any way I can piggyback a script onto another application, The Powder Toy, for example? I'm not new to OSX, I just don't have root privileges and can't install XCode.
Rembember, I can't install anything from source or use setup scripts, effectively annihilating py2app as an option.
EDIT:
This answer is courtesy of mklement0. Automator lets you choose the environment to run your script, type it in, and bundle it into a .app, removing the need for a shell script.
Run Automator and create a new Application project.
Add a Run Shell Script action.
In the Shell: list, select the interpreter of choice; /usr/bin/python in this case.
Paste the contents of your Python script into the action and save the *.app bundle.
if your using applescript, just save it as a bundle by save as, and click the drop down saying script, change that to bundle i think. after that, click on the bundle icon in apple script and drag the script to the folder you want. to run it put your run command in and drag the script that you placed in the bundle folders before in the directory slot of the run command. i can not give you anything exact due to the fact that i am not on my mac, but i am giving you the best i know.
Is there a way to control what version of python is run when double clicking on a py file? From the command line and in environments such as eclipse I can control what version is run. But from double clicking I am not sure.
I have 2.6 and 2.7 installed. 2.6 is for some application specific stuff and I want to make 2.7 the default. I have added "C:\Python27" to the PATH environment variable and that works well at the command line. C:\path\to\some\file>python someFile.py will run the file in 2.7. But if I double click the same file from explorer it runs 2.6. How to get it to run 2.7?
On Windows, you have to modify the file associations, for example via Right Click → Open with ... → Choose default program or the Control Panel's Folder Settings. You can choose between multiple python installations by navigating to the python.exe you want via the Browse button:
Alternatively, you can change the association in a command shell by typing
ftype Python.File="C:\Python27\python.exe" "%1" %*
Note that this requires administrator rights. If UAC is enabled on your machine, right click cmd in the start menu and select Run as administrator.
On freedesktop.org-compatible desktops, you can configure the association with xdg-mime.
On debian-based distributions, you can change the default python with update-alternatives. On all systems, you can also symlink the python in your path to the correct implementation, like this:
$ sudo ln -sf python2.7 /usr/bin/python
If the file is marked executable, it can also be executed directly from the command line or GUI if it starts with #! and the name of the interpreter:
#!/usr/bin/env python
To choose a specific Python version just for your program, you can start your Python program with one of the following lines:
#!/usr/bin/env python2.7
#!/usr/bin/python2.7
OK I have found the Python Launcher, which does exactly what I am after. Download can be found here. Installing this gave me the option for "Python Launcher for Windows (GUI)" when changing the file association via the right click menu.
Adding the shebang line
#!/usr/bin/python2.7
forces the script to run in 2.7.
This works great as I can control what version of python is running and users never need to know. No need for bat files, or dragging onto shortcuts etc. Nice and clean, and most importantly, no room for user error.
You can use ASSOC and FTYPE
assoc .py=pyfile
ftype pyfile=c:\Python27\python.exe %1
You will find answer in answers to the following questions:
How to execute python scripts in windows?
Using older Python 2.x while having both Python 2.x and 3.x installed on Windows
Temporary file association for single cmd.exe session
How to write a batch file showing path to executable and version of Python handling Python scripts on Windows?
I have some small utility scripts written in Python that I want to be usable on both Windows and Linux. I want to avoid having to explicitly invoke the Python interpreter. Is there an easy way to point shebang notation to the correct locations on both Windows and Linux? If not, is there another way to allow implicit invocation of the Python interpreter on both Windows and Linux without having to modify the script when transferring between operating systems?
Edit: The shebang support on Windows is provided Cygwin, but I want to use the native Windows Python interpreter on Windows, not the Cygwin one.
Edit # 2: It appears that shebang notation overrides file associations in Cygwin terminals. I guess I could just uninstall Cygwin Python and symlink /usr/bin/python to Windows-native Python.
Read up on the Python Launcher for Windows in the docs, which was initially described in PEP 397. It lets
you define custom shebang configurations in "py.ini" (e.g. to use pypy),
and out of the box you can use virtual shebangs such as #!/usr/bin/env python3, or shebangs with real paths such as #!"C:\Python33\python.exe". (Quoting is required for paths containing spaces.) You can also add command-line options to a shebang. For example, the following shebang adds the option to enter interactive mode after the script terminates: #!/usr/bin/python3 -i.
The installer associates .py (console) and .pyw (GUI) script file types with the respectively named launchers, py.exe and pyw.exe, in order to enable shebang support for scripts in Windows. For an all-users installation, the launchers are installed to the Windows folder (i.e. %SystemRoot%). For a per-user installation, you may need to manually add the installation directory to PATH in order to use py.exe in the shell (*). Then from the command line you can run Python via py -2, py -3, py -2.6, py -3.3-32 (32-bit), and so on. The launcher is handy when combined with -m to run a module as a script using a particular version of the interpreter, e.g. py -3 -m pip install.
(*) The new installer in 3.5+ defaults to "%LocalAppData%\Programs\Python\Launcher" for a per-user installation of the launcher, instead of installing it beside "python.exe", and it automatically adds this directory to PATH.
Unless you are using cygwin, windows has no shebang support. However, when you install python, it add as file association for .py files. If you put just the name of your script on the command line, or double click it in windows explorer, then it will run through python.
What I do is include a #!/usr/bin/env python shebang in my scripts. This allows for shebang support on linux. If you run it on a windows machine with python installed, then the file association should be there, and it will run as well.
Short answer:
The easiest way is to install git for windows wich comes with GitBash. Then add shebang lines in your scripts to indicate they should be run with python when executed.
#!/usr/bin/env python
More info:
Unlike Cygwin, git bash uses your native windows applications and lets you use bash scripts without any configuration.
It will automatically treat any file with a shebang line as executable the same way Linux shells do.
eg: #!/usr/bin/env php or #!/usr/bin/env node or any other application you want will work as long as you add the paths to your windows ENV path.
You can edit env vars in windows by hitting start and typing env should be the first option.
Git bash also installs git and hooks it up with a credentials manager for you and makes it super easy to sign into 2fa-enabled svn services and a ton of other handy developer features.
Git bash is IMO a must on every developer's machine.
Another option:
Install WSL (Windows Subsystem for Linux) which will work the same.
WSL also lets you install native Linux versions of all your command line applications if you prefer.
Linux binaries will take precedence over windows ones if installed but you can still choose to run the windows version of commands any time you want by specifically adding .exe on the end.
Install pywin32. One of the nice thing is it setups the file association of *.py to the python interpreter.
sorry for open old topic.
I create one file py.cmd and place it in the C:\Windows\System32 folder
py.bat:
#(
#set /p shebang=
)<%1
#set shebang=%shebang:#! =%
#%shebang% %1 %2 %3 %4 %5 %6 %7 %8 %9
py.bat file explain:
Get the first line from *.py file
Remove shebang characters "#! "
Run python file using shebang python path
All windows python script must start with shebang line as the first line in the code:
#! c:\Python27\python.exe
or
#! c:\Python37\python.exe
Then run it:
cmd> py SomePyFile.py param1 param1 paramX
Not with shebang ... but you might be able to set up a file association, see this SO question which deals with Perl and the associated answers which will also be pertinent as there's known problems with Windows and stdin/out redirection...