We Keep Coding

Is there a way to shorten command line commands to open Python scripts?

I'd like to know if there is a way to shorten what must be written on the cmd.exe command line to run Python programs. As it is, I have a program called Calculator.py and if I wanted to run that I would have to write:
python.exe C:\Users\user_name\restofdirectory\Calculator.py
Basically I want to know if I could make the 'Python' folder on my computer default so I could just type python.exe Calculator.py or some other similarly short way of doing it so I didn't have to type the whole directory.

Create a cmd.exe shortcut somewhere handy (Desktop or whatever). Right Click, select properties. Under the Shortcut tab you'll have a "Start In" field. It'll be default to wherever your cmd.exe normally opens. But you can change it to any path you want (So set it to your python development folder)-- then opening that shortcut will always start cmd.exe in the python folder.
You don't need to type python.exe file.py --
Just type: python file.py
So in short, you'd click that shortcut and type python file.py and you are done.
If you have specific scripts you want to run frequently, you can create a cmd.exe shortcut for each one. Set the Start In path to their folder. Then update the link to cmd.exe like this:
c:\path\to\cmd.exe /k python file.py
That will open a cmd prompt and automatically run that specific script

Yes, you can cd into the folder first.

If python is in your default path you can create a folder and put all your python scripts in it. Then cd into that folder and type python Calculator.py. To test if python is in your path simply open up a cmd and type cd \ (which in your case should change your working directory to C:\) then type python. If you get an error saying the command python cannot be found then you have to add python to your path. Other wise you should be able to run cd C:\Users\user_name\restofdirectory\ and then execute the script python Calculator.py

create an environment variable, say, PyPath = C:\Users\user_name\restofdirectory
then your line would be:
python.exe %PyPath%\Calculator.py
or you just cd to C:\Users\user_name\restofdirectory, and run
python.exe Calculator.py

Add Python to your path:
SET PATH=%PATH%;C:\Python27\bin
then you can call python like this:
python myapp.py

If you have the Python Launcher for Windows (comes with Python 3.3+) installed, then it gets even easier. You just need to put shebang in your code:
#! python
The first time you run your code, Windows will pop up a dialog and ask you what program to use to run the script. The Python Launcher should be listed. Just choose that and away you go. Here's a fun little script from the page I linked earlier:
#! python
import sys
sys.stdout.write("hello from Python %s\n" % (sys.version,))
Once my Windows 7 box had the launcher installed and I told it what program to run, I could just call my script from cmd.exe like this:
my_script.py
Note: If you have a version of Python older than 3.3, you can download the installer here

Trying to directly run .py file using Enthought Canopy Python on Windows 7

I am trying to set up Canopy with Windows so that it will not, by default, try to open as a GUI. Essentially I want to do exactly this:
http://docs.enthought.com/canopy/configure/canopy-cli.html#create-epd-dist
The only problem is that the instructions listed here do not seem to work as expected.
Here's what I want to happen. I have a folder full of scripts. The folder (my_program/) is in my path. I want to call script_1.py on the command line from any directory and have it execute. With the old Enthought distribution this is what happens. It is also what happens with Canopy on Mac. However, running Canopy on Windows, instead the Canopy GUI pops up with script_1.py open for editing.
I ran this command as in the docs:
Canopy\App\Canopy_cli.exe setup C:\Python27 --set-default
It created a "Canopy 64 bit (standalone) Command Prompt" in addition to the regular Command Prompt. However, the behavior in both this new Command Prompt and the regular Command Prompt remains the same -- script_1.py simply opens the Canopy GUI.
Here is my PATH variable:
c:\python27\scripts;
c:\users\****\appdata\local\enthought\canopy\user\scripts;
C:\Users\****\AppData\Local\Enthought\Canopy\User;
C:\Users\****\AppData\Local\Enthought\Canopy\User\Scripts;
C:\Python27;
C:\Python27\Scripts;
C:\Users\****\Documents\my_program;
Any ideas why I'm not able to set up Canopy as an EPD-like environment, or how to do so? Thanks!
Update:
First, I ran this command as Jonathan March outlined in his answer:
ftype Python.File=c:\Users\**\AppData\Local\enthought\Canopy\User\Scripts\python.exe %1
However, with this the behavior remained the same. The above turned out to be half of the solution.
Fortunately, I was able to get it working using regedit. I had to edit Computer\HKEY_CLASSES_ROOT.py by changing the default from "Enthought.Canopy" to "Python.File". And I also changed Computer\HKEY_CLASSES_ROOT.py\OpenWithProgIds by deleting the "Enthought.Canopy" key and adding a "Python.File" key.
I'm really happy to have it working, however mucking around with regedit is a difficult task for Windows users of my software. Now I'm wondering, is there a simpler way to do this, perhaps in the install script that puts my folder of command-line scripts into their path? Any ideas are appreciated.

Sorry for the confusion -- "EPD-like" refers to running python directly, not to the windows file associations, but I can definitely see your point. Here's how to get what you want:
1) Even if you are a full admin on this system, open an "Administrator:Command Prompt" window as described in in steps 1 and 2 in this article: https://support.enthought.com/entries/23736288-Windows-On-some-systems-admin-users-cannot-immediately-install-for-all-users-
2) In this window, type the following command at the command prompt:
ftype Python.File=c:\Users\**\AppData\Local\enthought\Canopy\User\Scripts\python.exe %1
Test that it now works as desired, then close this window.

Linux desktop file Exec doesn't used the user session

I have a python script file that works perfectly when I use it from the terminal.
Now I have created the following .desktop file in order to launch it easily:
[Desktop Entry]
Name=Test
GenericName=Test
Comment=My test script
Type=Application
Exec=/opt/test.py
Icon=/opt/test.png
Categories=Utils;
When I launch it the GTK window appear but clicking a button that call an init.d script make it working not properly.
Therefore adding Terminal=true make it working perfectly but I don't want to have that terminal open.
So I have then put the following code in order to log the environment variables:
import os
with open("/tmp/py_env.log", "w") as env_log:
env_log.write(str(os.environ))
and found differences.
So my question is how to write the .desktop file so that my application is running like if I start it from my terminal (without having an opened terminal :))

The problem is valid, but I think "replicating the terminal environment" is the wrong approach to solve it.
Indeed, what makes the application work is not the fact that it's launched from the terminal, it's that the terminal happens to have some environment variables which matter to your application.
Therefore, what you should aim for is to have those environment variables set properly at all times, rather than assuming the terminal environment will always happen to contain them all the time for all your users.
Thus, you should:
Check which environment variables are different between the two environments
Make a list of those which matter (i.e. those which would make the .desktop file work properly), and of what their value needs to be for the script to work
Either:
Create a wrapper script for your Python script, which initializes those environment variables properly, OR
Set those environment variables from inside the Python script itself.

this question is similar to .bashrc not read when shell script is invoked from desktop shortcut
either initialize your environment in ~/.bash_profile instead of
~/.bashrc
OR
make your *.desktop file call a wrapper that initializes your
environment - e.g. by sourcing ~/.bashrc (or whatever script is
responsible now).
the second solution is more specific (does not effect all other unrelated launches of your shell) in should thus be preferred.

Thanks anyone to have participate to this question.
I have solved this issue by implemented use of pkexec instead of gksudo.
pkexec seems to reuse the current user environment then I don't have this issue anymore.
Thanks.

Python Beginner: ImportError when run from NP++ but not IDLE

I am using Python 3.3 (2.7 is also installed) and a compatible version of pygame. Recently I have been trying to switch from IDLE to Notepad++
I am using a saved shortcut in Notepad++
C:\Python33\python.bat "$(CURRENT_DIRECTORY)" "$(FILE_NAME)"
which runs the batch file:
#echo off
cd %1
%2
if not errorlevel 1 goto quit
echo.
echo.
pause
:quit
When I run C:\Python33\Foldername\imp_prob.py
import pygame
in IDLE it works fine, in Notepad++ using that shortcut it gives an ImportError: No module named pygame
My questions are:
Why is the NP++ method not producing the same result?
How can I change the shortcut or batch file to make it run stuff that IDLE can run?
What method can I use to ensure that I can import a module regardless of which directory I am running the program from?
edit: a working alternative was in the answers to How do you run a python script from within notepad++?
I had some issues with the code they provided, but replacing "python" with the full path to my python33 install solved that.
I still don't understand why pygame wouldn't import when using my run shortcut. I also don't understand why NppExec works when Run doesn't.

It sounds like you would need to set your systemvariables. Idle does not require these steps. You entered the full path to the python.exe in np++ to execute the python program, but the path to the modules etc. is still unknown.
Add the paths, and try again.
System Properties -> Advanced -> Environment Variables, in the bottom window look for a "Path" variable, Edit and append the following the existing entries (do not delete anything in there!)
;C:\Python33;C:\Python33\DLLs;C:\Python33\Lib
for Python 3.3, if you have installed it into its default directory.
To see if everything worked, open the console anywhere (shift+rightclick -> Open Command Window Here) and just type "python". The python console should open, telling you that you use python 3.3. You then also do not need to tell np++ the full python path, but instead can just use "python" again.

Default Folder for Terminal in OSX, When Running Python Interactive Shell

This is a follow up question as I'm trying to move forward with Zelle's Python:Programming.
It appears that IDLE 2.7.2 has hang issues when opening graphics windows in interactive mode. But, I can simply run Python interactively in Terminal and don't have any of those issues. So that's a big help. Zelle provides a simplified graphics file called graphics.py, to get up to speed with objects and graphics, before dealing directly with Tkinter.
My question is this. Where should I put graphics.py, so Terminal will see it (when it's called), without including the full path every time? Thanks,
Henry

According to PEP 0370, a good place to put your user packages is in ~/.local/lib/python2.7/site-packages.
Modules in here should be importable.

You can modify your ~/.bashrc to include a PYTHONPATH definition that includes the location of the file.
export PYTHONPATH="/path/to/directory_containing_graphics.py"
Just be careful if it's in your home director to use /Users/[username]/etc/directory_containing_graphics.py, I vaguely recall being bitten by ~ not expanding like I expected one time on OS X.

I went deep down the rabbit hole to get to bottom of this issue. It turns out that bash on OSX has a few quirks, not unexpected with the various flavors of UNIX around. It turns out that when firing up a bash shell, bash looks in .bash_profile for config statements. If you enter bash into bash, you fire up a sub shell, and that's when and only when .bashrc is executed.
To make sure you only have to manage one config file, put:
if [ -f ~/.bashrc ]; then
source ~/.bashrc
fi
in your .bash_profile. This just tells bash to look into the .bashrc file if it exists. You can then leave that file alone and only modify your .bashrc file and all instances of bash will be modified the same. Once I figured this out, I still had to solve my problem. Here's the best I could do. When Python installed it installed this into my .bash_profile:
PATH="/Library/Frameworks/Python.framework/Versions/2.7/bin:${PATH}"
export PATH
This tells bash where to look for the libraries needed to run Python. So I moved this statement to my .bashrc file after putting the "if" statement into my .bash_profile. I then tried adding a : to the PATH statement with the path to my Python modules, but that didn't work. So, I have settled for a statement like this in .bashrc:
PYTHONPATH=$PYTHONPATH:/Users/ftpbub/Documents/workspace/Python\ Programming\ Modules/src/
export PYTHONPATH
Now I enter python at the command prompt, and when I get to python, I can enter import modulename without the path and it works. If I start a new project in a new directory, I should be able to add it to my PYTHONPATH and be good. I would have liked to be able to enter python modulename right into bash and have the module execute, but I haven't figured out how to do that. Other than that, I think this the best I can do. Ideas for how to go straight to the module from the bash prompt, without entering the path?