Site Navigation
|
|
PGTS Humble BlogThread: Tips/Tricks For Programming etc |
|
 |
Gerry Patterson. The world's most humble blogger |
| Edited and endorsed by PGTS, Home of the world's most humble blogger | |
| | |
Setting File Associations with ASSOC and FTYPE in Windows 7 |
|
Chronogical Blog Entries:
|
|
| | |
Date: Thu, 31 Jul 2014 23:14:10 +1000In the past the ASSOC and FTYPE commands in Windows have been commands that although not used frequently were often invoked after an installation of perl on Windows. Lately however I have encountered some issues with file associations on Windows 7 workstations. |
|
According to the help screen for FTYPE ... The command should work as it always has ... The Windows 7 help screen for FTYPE is as follows:
C:\Users\FOO.BAR>ftype /? Displays or modifies file types used in file extension associations FTYPE [fileType[=[openCommandString]]] fileType Specifies the file type to examine or change openCommandString Specifies the open command to use when launching files of this type. Type FTYPE without parameters to display the current file types that have open command strings defined. FTYPE is invoked with just a file type, it displays the current open command string for that file type. Specify nothing for the open command string and the FTYPE command will delete the open command string for the file type. Within an open command string %0 or %1 are substituted with the file name being launched through the association. %* gets all the parameters and %2 gets the 1st parameter, %3 the second, etc. %~n gets all the remaining parameters starting with the nth parameter, where n may be between 2 and 9, inclusive. For example: ASSOC .pl=PerlScript FTYPE PerlScript=perl.exe %1 %* would allow you to invoke a Perl script as follows: script.pl 1 2 3 If you want to eliminate the need to type the extensions, then do the following: set PATHEXT=.pl;%PATHEXT% and the script could be invoked as follows: script 1 2 3 |
That's jolly decent of Microsoft ... Giving us an example for .pl ... Which is after all, probably the most common usage programmers have for resorting to the ASSOC and FTYPE commands ... And according to the Windows 7 help screen for the ASSOC the command, it also works as it always has ...
C:\Users\FOO.BAR>assoc /? Displays or modifies file extension associations ASSOC [.ext[=[fileType]]] .ext Specifies the file extension to associate the file type with fileType Specifies the file type to associate with the file extension Type ASSOC without parameters to display the current file associations. If ASSOC is invoked with just a file extension, it displays the current file association for that file extension. Specify nothing for the file type and the command will delete the association for the file extension. |
At a glance, it all seems good ... However a couple of recent encounters with Windows 7 has revealed that this is not entirely correct ... I have found that generally Windows 7 workstations do not have these values set and I have had questions from Windows 7 users, which makes me think that some of this functionality has been migrated to the GUI.
To try and explore this further I tried a standard install of Strawberry perl ... I found the following:
C:\Users\FOO.BAR>assoc .pl .pl=Perl_program_file |
I went looking for the program that would run it ...
C:\Users\FOO.BAR>ftype | findstr Perl |
And that returned nothing (WTF?!) ... This lead me to wonder if .pl associations would work ... I created a quick perl script:
C:\Users\FOO.BAR>echo #!/bin/perl > hello.pl C:\Users\FOO.BAR>echo print "hello world\n"; >> hello.pl C:\Users\FOO.BAR>hello hello world |
Yep, it works ... But ... How is this so? Then I thought ... Maybe it is in the registry? It seems to be where Microsoft put everything these days
C:\Users\FOO.BAR>reg query HKLM\Software /s | findstr Perl_program_file 2>null (Default) REG_SZ Perl_program_file HKEY_LOCAL_MACHINE\Software\Classes\Perl_program_file HKEY_LOCAL_MACHINE\Software\Classes\Perl_program_file\shell HKEY_LOCAL_MACHINE\Software\Classes\Perl_program_file\shell\Execute Perl Program HKEY_LOCAL_MACHINE\Software\Classes\Perl_program_file\shell\Execute Perl Program\command |
Probably the command above betrays my Unix roots ... Windows command line veterans would know that there is a /F switch for REG QUERY ... Which would have given me the sub key I was searching for ... i.e. (now that I remember it ... It all comes back like an old nightmare about Windows registry):
C:\Users\FOO.BAR>reg query HKLM\Software /s /f Perl_program_file HKEY_LOCAL_MACHINE\Software\Classes\.pl (Default) REG_SZ Perl_program_file HKEY_LOCAL_MACHINE\Software\Classes\Perl_program_file End of search: 2 match(es) found. C:\Users\FOO.BAR>REG QUERY HKLM\Software\Classes\Perl_program_file /s HKEY_LOCAL_MACHINE\Software\Classes\Perl_program_file (Default) REG_SZ Perl program file HKEY_LOCAL_MACHINE\Software\Classes\Perl_program_file\shell HKEY_LOCAL_MACHINE\Software\Classes\Perl_program_file\shell\Execute Perl Program HKEY_LOCAL_MACHINE\Software\Classes\Perl_program_file\shell\Execute Perl Program\command (Default) REG_SZ "C:\strawberry\perl\bin\perl.exe" "%1" %* |
Maybe a "real" Windows user would have used the GUI interface (REGEDIT) ... But this lead me to wonder whether ASSOC actually works in Windows 7. A few experiments convinced me that it does. So if you set the associations with FTYPE and ASSOC ...
C:\Users\FOO.BAR>ftype Perl_program_file=C:\strawberry\perl\bin\perl.exe %1 %* Perl_program_file=C:\strawberry\perl\bin\perl.exe %1 %* C:\Users\FOO.BAR>assoc .pl=Perl_program_file .pl=Perl_program_file C:\Users\FOO.BAR>setx /m pathext .COM;.EXE;.BAT;.CMD;.PL;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC |
Or you might prefer to get rid of .VBS .VBE etc?
Next login as another user and all associations have been set ok ... Provided you modified the environment variable PATHEXT ... If you use SETX with the /m option as above rather than SET the change is permanent ... Provided you have admin access (have to logout and login for the environment change to take effect)
The ASSOC command changes this key:
HKLM\Software\Classes\Perl_program_file\shell\Open\Command
Possibly the difference in keys is due to one of them being tailored for a GUI interface such as Windows explorer file browser and the other tailored for the command line? Difficult to know because they seem to work ... Not sure what might happen if there were conflicts or one of them over-rode the other ... Perhaps someone has done some research on this?
And just for the record I don't think users should be starting executables in the client environment or invoking powerful interpreters like perl, python (or especially pre-installed Microsoft interpreters such as WScript) with a single click of a mouse from a GUI window. And that applies especially to an MUA window (e.g. Microsoft Outlook ... The most common vector for malware these days).
While all the dangerous file associations are still there ... One annoying feature about Windows 7 is that some useful associations (like .wri with a wordpad file) no longer exist. Associations to .wri are either missing or mapped to NOTEPAD.EXE. Unfortunately notepad does not "grok" Unix files ... I find it easiest to send text attachments as .wri to non-technical users. In the past these referred to files written by Microsoft WRITE. Later WRITE was replaced with WORDPAD. Either of these Microsoft programs understand Unix style text files (terminated with a "\n" character only).
It's difficult to understand why Windows 7 didn't ship with associations such as .wri with WORDPAD ... Seeing as how Windows 7 engineers want us to cling to the buggy (and dangerous) .vbs associations.
Assuming that your system has the assoc .wri=textfile You could change it with these commands:
C:\Users\FOO.BAR>ftype wri_file=C:\windows\system32\write.exe "%1" ftype wri_file=C:\windows\system32\write.exe "%1" C:\Users\FOO.BAR>assoc .wri=wri_file .wri=wri_file |
Or you can use the program "%ProgramFiles%\Windows NT\Accessories\WORDPAD.EXE" ... If you have it.
To explain it to a GUI user, ask them to open the properties window of .wri file in Windows explorer and change it to "always open this type of file with WORDPAD" ... Or words to that effect ...
They will have to turn off word-wrap in WORDPAD or WRITE ...
If you are setting up a machine for your own use, you might want to set .wri to the type txtfile and associate txtfile with GVIM.
Much of this may depend on your local support group, who probably setup domain policies that are almost exclusively tailored for GUI use.