Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I associated Python's interpreter with Python scripts using environment variable:

C:\Users\Piotr>ftype Python.File
Python.File="%PYTHON_HOME%\python.exe" "%1" %*

Sometimes this environment variable is unset or set to non-existing path. When it's the case and I try to run Python script like this

C:\Users\Piotr>some_script.py

a dialog window titled Open With pops up.

I'd rather get some error info in the command line window instead of this dialog. How can I prevent this dialog from popping up in this situation?

share|improve this question

2 Answers 2

My over-convoluted answer:

Permanently set the environment variable:

%PYTHON_HOME%=C:\Python\NotReady

Then in that folder create a small program named python.exe that displays an error message, or better yet, starts the python initialisation script.

share|improve this answer
    
Nice idea but it won't fly. It doesn't work neither for empty environment variable (after some script set it empty) nor for invalid environment variable (after some script set it to such). –  Piotr Dobrogost Oct 20 '11 at 19:43
    
Don't make it empty or invalid. Make it legit. Make the folder described in the environment variable, make a dummy program named python.exe, and place it in that folder. –  Hand-E-Food Oct 20 '11 at 22:16
    
It's only ok as long as the variable is set properly. I'm concerned with the situation when it's not. I already have this variable set by default to point to my default Python interpreter. The problem raises when for example I misuse some script which sets this variable and variable's contents is garbage after that. –  Piotr Dobrogost Oct 20 '11 at 22:31
    
Okay, now I understand. I didn't understand that the Python variable was correctly set by default. I thought it was blank by default and you had to run a script to initialise it's variables and other settings first. –  Hand-E-Food Oct 20 '11 at 22:40

You could try testing the result of executing ASSOC .py before actually invoking the script:

ASSOC .py >nul && some_script.py

The ASSOC .py command displays the file type associated with the .py extension, if any. If there's no association (which must be true when there's no Python installed in the system), the command sets the ERRORLEVEL system variable.

Now, the command before the && command delimiter is only executed if the previous command hasn't set ERRORLEVEL. So, if there's no file type association for .py in the system, the script will not be invoked. Also you'll get a relevant message from ASSOC in the command window. (>nul suppresses 'normal' output, but doesn't suppress the No association message.)

share|improve this answer
    
Nice idea. However, Your statement If there's no association (which must be true when there's no Python installed in the system) is not true. But inspired by your answer I came up with solution I guess. We can try to invoke associated executable before invoking script to test if the associated executable really exists. –  Piotr Dobrogost Oct 22 '11 at 8:39
    
Oh, in that case you might not need to invoke it, just check for its existence: IF EXIST associated_exe some_script.py. I'm somewhat surprised that the system may recognise an extension like .py as a registered file type and not have the corresponding executable for opening the files, though. My system, for one, doesn't recognise the .py extension as a registered type. Do you possibly mean the situations when the association remains after de-installing Python? –  Andriy M Oct 22 '11 at 10:36
    
Do you possibly mean the situations when the association remains after de-installing Python? This or when someone creates or changes association manually. –  Piotr Dobrogost Oct 22 '11 at 12:50

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.