PGTS PGTS Pty. Ltd.   ACN: 007 008 568

point Site Navigation

point Other Blog Threads

  Valid HTML 4.01 Transitional

   Stop The Internet Filter!

   No Clean Feed

   The Internet Filter Is An Ex-parrot!

PGTS Humble Blog

Thread: Tips/Tricks For Programming etc

Author Image Gerry Patterson. The world's most humble blogger
I know not with what weapons World War III will be fought, but World War IV will be fought with sticks and stones -- Albert Einstein, 1948

Setting File Associations with ASSOC and FTYPE in Windows 7

Chronogical Blog Entries:

Date: Thu, 31 Jul 2014 23:14:10 +1000

In 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: 1 2 3

If you want to eliminate the need to type the extensions, then do the


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

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 >

C:\Users\FOO.BAR>echo print "hello world\n"; >>

    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\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

    (Default)    REG_SZ    Perl_program_file


End of search: 2 match(es) found.

C:\Users\FOO.BAR>REG QUERY  HKLM\Software\Classes\Perl_program_file /s

    (Default)    REG_SZ    Perl program file


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

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:


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

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.

Other Blog Posts In This Thread:

Copyright     2014, Gerry Patterson. All Rights Reserved.