ThePATH environment variable lists all the locations that Windows (and cmd.exe) will check when given the name of a command, e.g. "python" (it also uses the PATHEXT variable for a list of executable file extensions to try). The first executable file it finds on the PATH with that name is the one it starts.
Note that after changing this variable, there is no need to restart Windows, but only new instances of cmd.exe will have the updated PATH. You can type set PATH at the command prompt to see what the current value is.
It has taken me some effort looking for answers here, on the web, and and in the Python documentation, and testing on my own, to finally get my Python scripts working smoothly on my Windows machines (WinXP and Win7). So, I just blogged about it and am pasting that below in case it's useful to others. Sorry it's long, and feel free to improve it; I'm no expert.
[UPDATE: Python 3.3 now includes the Python Launcher for Windows, which allows you to type py (rather than python) to invoke the default interpreter, or py -2, py -3, py -2.7, etc. It also supports shebang lines, allowing the script itself to specify. For versions prior to 3.3, the launcher is available as a separate download. ]
Maybe you're creating your own Python scripts, or maybe someone has given you one for doing something with your data files. Say you've acquired a Python script and have saved it to "D:\my scripts\ApplyRE.py". You want to run it conveniently by either double-clicking it or typing it into the command line from any location, with the option of passing parameters to it like this (-o means "overwrite the output file if it already exists"):
Say you also have a data file, "C:\some files\some lexicon.txt". The simplest option is to move the file or the script so they're in the same location, but that can get messy, so let's assume that they'll stay separate.
Verify that double-clicking on ApplyRE.py runs it. (It should also have a Python logo as its icon and be labeled "Python File", by the way.) If this isn't already done, right-click on a .py file, choose Open With, Choose Program, and check "Always use..." This association improves convenience but isn't strictly necessary--you can specify "python" every time you want to run a script, like this:
But that's a pain. Fortunately, once Python is installed, in the PATH, and associated with .py, then double-clicking a .py file or directly typing it as a command should work fine. Here, we seem to be running the script directly--it's nice and simple to run it on a sample file that's located in the "my scripts" folder along with the script.
To further reduce typing, you can tell Windows that .py (and perhaps .pyc files) are executable. To do this, right-click Computer and choose Properties, Advanced, Environment Variables, System Variables. Append ";.PY;.PYC" (without quotes) to the existing PATHEXT variable, or else create it if you're certan it doesn't exist yet. Close and reopen the command prompt. You should now be able to omit the .py (FYI, doing so would cause ApplyRE.exe or ApplyRE.bat to run instead, if one existed).
If you're going to use your scripts often from the command prompt (it's less important if doing so via using BAT files), then you'll want to add your scripts' folder to the system PATH. (Next to PATHEXT you should see a PATH variable; append ";D:\my scripts" to it, without quotes.) This way you can run a script from some other location against the files in current location, like this:
If .py is associated with an installed Python, you can just double-click ApplyRE.py to run it, but the console may appear and disappear too quickly to read its output (or failure!). And to pass parameters, you'd need to first do one of the following.(a) Right-click and create a shortcut. Right-click the shortcut to edit properties and append parameters to Target.(b) Create a batch file--a plain text file with a distinct name such as ApplyRErun.bat. This option is probably better because you can ask it to pause so you can see the output. Here is a sample BAT file's contents, written to be located and run from c:\some files .
This usually isn't necessary, but one other environment variable that may be relevant is PYTHONPATH. If we were to append d:\my scripts to that variable, then other Python scripts in other locations could make use of those via import statements.
I also found the same problem even though i've added the path in the environment variable. Finally, I put my "C:\Python27" in the FRONT part of the "PATH" in environment variable and after restarting the cmd, it works!!! I hope this can help.
If the option was not checked, then please use Set Path in cmd to see if it is available as executables or not. If not, Navigate to Start >> Control Panel >> System and Security >> System >> Advanced System Settings >> Advanced >> Environment Variables.. >> Select PATH from System Variables and Edit it. Then copy "C:\Python35\cmd" in the new line. After this please add .PY to PATHEXT in the same procedure.
Goto the Start MenuRight Click "Computer"Select "Properties"A dialog should pop up with a link on the left called "Advanced system settings". Click it.In the System Properties dialog, click the button called "Environment Variables".In the Environment Variables dialog look for "Path" under the System Variables window.Add ";C:\Python27" to the end of it. The semicolon is the path separator on windows.Click Ok and close the dialogs.Now open up a new command prompt and type "python"
Go to the path where python is installed (type in python to start menu and open file location). On the address toolbar, type in the version of the Python - for me it's Python 3.10 (64-bit) and press enter. The command prompt will open up with the exact path where python is saved, so that the code will work. Same principle if you have installed Jupyter Notebook on your drive. Go to the folder where Jupyter is saved and type in Jupyter Notebook on the address bar and press enter. Easier than changing system paths..
LinkedIn and 3rd parties use essential and non-essential cookies to provide, secure, analyze and improve our Services, and to show you relevant ads (including professional and job ads) on and off LinkedIn. Learn more in our Cookie Policy.
Microsoft is working in a novelty! Linux command line tools in Windows 10!
My 1st thought about this is that Microsoft, with this new features, is trying to re-conquer developers and sys admins that along time ago decided to go Mac OS X or Linux distributions has their main workstation environment.
For sure this will be a challenge for Microsoft, perfectly aligned with its Linux friendly approach.
This isn't cross-compiled, it isn't a virtual machine, as Microsoft proudly announced on stage. This is the real, proper Bash on Windows 10. Microsoft has partnered with Canonical to include native Ubuntu binaries in the OS, and it can be downloaded directly from the Windows Store. You'll get access to native APIs, File System, VT100 and SSH support, as it brings "the power of open source command line tools to Windows." in -shell-officially-coming-windows-10
For me that have been following Microsoft for quite some years, it's strange to see Microsoft sifting is strategy in this last few years. 10 years ago, it was (at least for me) not imaginable that this so big company could look at non-Microsoft alternatives as a business reality.
Being Mac OS a real desktop alternative to Windows, this will make people think a lot more in the moment of choosing a new laptop or desktop. Alternatively Linux distributions are losing ground to this alternative since the open source world are spending too much time creating new graphical desktop environments that are nice to have, but in reality they don't bring value to companies and users.
3a8082e126