Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

WAD Take Command ignoring my application-extension associations

Jul
37
0
This problem has caused a whole lot of heartache in the past 48 hours.

Install Python 3.4.1: https://www.python.org/downloads/windows

Create a file named temp.py, which contains a single line:

Code:
print("Hello")

I've saved mine on the desktop.

Executing this in Take Command fails:

tP9HXtc.jpg


Yet it works in Console2:

PH2uUWN.jpg


PowerCmd

DSe1uwS.jpg


And cmd.exe

5excAHk.jpg


It seems that Take Command is ignoring the Windows file associations. More information: http://stackoverflow.com/questions/...n-works-with-full-command-but-file-py-version

Please: How can I fix this?
 
This problem persists regardless the value of the Options > Configure TCC options > Startup > PathExt

I have read the help documentation sections on "PATHEXT" and "
Windows File Associations" (and the sections it links to), but I'm not understanding it.
 
TCC claims to support Python 3.1, 2.6, and 2,5 ("in that order"). My guess is that you have Python support enabled (OPTION\Startup) and that TCC is trying (but failing) to load a python DLL; maybe 3.4 is not supported. The other apps you mentioned (CMD, et al.) are probably running python.exe.
 
Thanks for the idea, vefatica.

I've tried it with all combinations of checking and unchecking

Options > Startup > Python

and

Options > Startup > PathExt

It still responds with "Cannot load Python dll"
 
Is the location of python.exe (and dll) in TCC's path? What is the registered handler for .PY?
 
I don't know what the TCC path is. My Windows path is

Code:
C:\applications\programming\python_341\DLLs;
C:\applications\programming\python_341\;
C:\applications\programming\python_341\Scripts;
C:\applications\programming\;
.;
C:\Program Files\Common Files\ArcSoft\Bin;
C:\Program Files\Common Files\Microsoft Shared\Windows Live;
C:\Program Files\Windows Live\Shared;
C:\Windows;
C:\Windows\System32\Wbem;
C:\Windows\System32\WindowsPowerShell\v1.0\;
C:\Windows\system32;
C:\applications\programming\apache-ant-1.8.1\bin;
C:\applications\programming\apache-maven-3.1.1\bin;
C:\applications\programming\jdk_7_51\bin;
C:\applications\video\quicktime\QTSystem\;
C:\Program Files\TortoiseSVN\bin;
C:\applications\programming\apache-maven-3.2.2\bin;
C:\applications\utilities\gpg4win\pub

R3cVYAq.jpg
 
In an instance of TCC, issue he command PATH. See if the python directories are there. Depending on how you start TCC, it may not be getting an updated path.
upload_2014-8-2_0-55-47.png
 
I wonder if this is related in any way to the problem I and others have reported with the ".pl" extension for Perl scripts. One participant here found that if the extension ".prl" is used and you've executed "set .prl=perl.exe", then naming a script (say) "test.prl" enables you to execute "test.prl" without an error message. This did not happen with older versions (I mean, with 4NT).
 
I tried your idea mikea, but it doesn't seem to be catching.

Code:
[C:\Users\jeffy\Desktop]temp
TCC: Could not load Python dll
[C:\Users\jeffy\Desktop]set .py=python.exe
[C:\Users\jeffy\Desktop]temp
TCC: Could not load Python dll
[C:\Users\jeffy\Desktop]set .py=C:\applications\programming\python_341\python.exe
[C:\Users\jeffy\Desktop]temp
TCC: Could not load Python dll
[C:\Users\jeffy\Desktop]

vefatica, the path in TCC is exactly the same as the windows Path (I added line breaks):

Code:
[C:\Users\jeffy\Desktop]path
PATH=C:\applications\programming\python_341\DLLs;
C:\applications\programming\python_341\;
C:\applications\programming\python_341\Scripts;
C:\applications\programming\;
.;
C:\Program Files\Common Files\ArcSoft\Bin;
C:\Program Files\Common Files\Microsoft Shared\Windows Live;
C:\Program Files\Windows Live\Shared;
C:\Windows;
C:\Windows\System32\Wbem;
C:\Windows\System32\WindowsPowerShell\v1.0\;
C:\Windows\system32;C:\applications\programming\apache-ant-1.8.1\bin;
C:\applications\programming\apache-maven-3.1.1\bin;
C:\applications\programming\jdk_7_51\bin;C:\applications\video\quicktime\QTSystem\;C:\Program Files\TortoiseSVN\bin;
C:\applications\programming\apache-maven-3.2.2\bin;
C:\applications\utilities\gpg4win\pub

[C:\Users\jeffy\Desktop]
 
Last edited:
TCC's help says:
Code:
TCC supports version 3.1, 2.6, and 2.5. (TCC will search for the Python dll's in that order.)
So I guess the python DLLs have versions numbers included in their names. And TCC is definitely not looking for the one you have.
So, at least for now, OPTION\Startup\Python should be unchecked. If it's unchecked, TCC should not be trying to load a python DLL, and mikea's executable extension idea should work (so should the ordinary Windows file association).

Do either of these work?
Code:
[C:\Users\jeffy\Desktop]python temp.py
[C:\Users\jeffy\Desktop]C:\applications\programming\python_341\python.exe temp.py
 
Once again, I'm not seeing anything like what you post. I just installed Python via the link you provided:

Code:
C:\Users\Charles\Desktop>type temp.py
print("Hello")

C:\Users\Charles\Desktop>temp
TCC: Unknown command "temp"

C:\Users\Charles\Desktop>temp.py
Hello

C:\Users\Charles\Desktop>which temp.py
temp.py is associated with : C:\Windows\py.exe

C:\Users\Charles\Desktop>

I'm not doing anything special; the Python option is turned off and I never ever use PathExt.

Have you tried setting an environment variable...?
Code:
set .py=c:\python34\python.exe
 
Charles, what's C:\Windows\py.exe (and it's relation to c:\python34\python.exe)?

Do the python DLLs have version numbers in their names? Can you trick TCC by making copies of them with names that TCC looks for (and then use the internal support)?
 
Charles, what's C:\Windows\py.exe (and it's relation to c:\python34\python.exe)?

I honestly know nothing about Python. The date stamp matches the files created in C:\PYTHON34\ by the installer, so I assume the installer created it along with the rest of the Python stuff.
 
This problem persists regardless the value of the Options > Configure TCC options > Startup > PathExt


Aha! *facepalm* Don't do that! Stop doing that! Forget that menu option is there!

To change TCC's configuration, use the OPTION command. Don't mouse through the Take Command menu option. You get an identical-looking dialog, but that one sets default options for new instances of TCC; it does not affect any currently running TCC session(s). Please type OPTION at the command line and press Enter, then select the 'Startup' tab and turn the 'Python' and 'PathExt' options off.

Note to Rex: Please consider changing the tooltip text on that button. "Configure TCC options" is confusing to the point of misleading. How about "Configure defaults for new TCC tabs"? Awkward, but it would tell the user what the button really does.
 
Considering the differences in the error messages, the .pl extension problem might not be related after all. Say 'test.pl' is a script that prints only "Hello, world".

c:\testing> eset .pl
.pl=perl.exe
c:\testing> test.pl
Error (SYS): Invalid class string
c:\testing> perl test.pl [or cmd /c test.pl]
Hello, world
Then:

c:\testing> set .prl=perl.exe
c:\testing> eset .prl

.prl=perl.exe
c:\testing> ren test.pl test.prl
c:\testing\test.pl -> C:\testing\test.prl
1 file renamed
c:\testing> test.prl
Hello, world
FWIW, I have the 'scripting' option set to 'Perl'. 'PathEXT' is NOT checked. (Using TCC only, and still back one version (TCC 15.01.52 x64).
 
This problem has caused a whole lot of heartache in the past 48 hours.

Install Python 3.4.1: https://www.python.org/downloads/windows

This is a problem with Python 3.4, not Take Command / TCC.

The developers of Python have had a really obnoxious (and pointless) habit of changing the Python dll name in every update. This means that TCC has to look for eight different python*.dll names in order to dynamically load the Python library. With 3.4 they've changed it again, though this time to "python3.dll" which hopefully indicates that they might actually retain the same name for a couple of builds. (Previous Python 3.x names were "python31.dll", "python32.dll", and "python33.dll".)

Python 3.4 was released three months after TC v16, so TCC doesn't know anything about the new python3.dll name. I will add that to the next version of TC -- it will require some additional testing because they also keep changing the initialization & termination calls.
 
>> This problem persists regardless the value of the Options > Configure TCC options > Startup > PathExt

> Aha! *facepalm* Don't do that! Stop doing that! Forget that menu option is there!
> To change TCC's configuration, use the OPTION command. Don't mouse through the Take Command menu option. You get an identical-looking dialog, but that one sets default options for new instances of TCC; it does not affect any currently running TCC session(s).

I understand this does not affect currently open sessions. Opening a new sessions sucks up all configuration settings at startup, and then ignores any changes while it's open. I believe that's correct.

How can I configure TCC to not look for the DLL at all, but instead "pass" this task to Windows, as all the other shells (Command2, PowerCmd, cmd.exe) do?
 
How can I configure TCC to not look for the DLL at all, but instead "pass" this task to Windows, as all the other shells (Command2, PowerCmd, cmd.exe) do?

Type OPTION and press Enter. Select the Startup tab, and turn off the Python option. I recommend also turning off PathExt if it's on. Click on OK.

(Incidentally, "all the other shells" you list are the same shell; Command2 and PowerCmd are just wrappers around CMD.EXE. So it's no surprise that they behave the same.)
 
I came here for the perl solution. It appears to be, "type option, uncheck perl, restart TCMD - don't believe it's lies about applies!" ;)
 

Similar threads

Back
Top