type also works provided you do something else first in the same command, or if you use a redirection:

system "cd && type file";
## or
system "ver && type file";
## or
system "type file > CON";
[download]

There is code internal to the system function that attempts to decide if it can get away with running the command you've supplied directly as an executable without invoking a copy of the shell. That is, if the command you ask it to run is an executable, then it runs that executable directly, but if it is a cmd.exe built-in command, then it runs cmd.exe with your input as the command line.

One of the ways it make this determination is to scan the path and look to see if there is an executable with the name of the first token you enter. Ie. When you supply "type file", it goes looking through your path looking for "type.exe". If that isn't found, then it will invoke "cmd /c type file", which will probably work.

But if like me you have Unxtools somewhere in your path, then it will find the ever useful and wonderfully named type.exe:

C:\test>U:type.exe -h
Usage: U:type.exe -v          ==> version
       U:type.exe -h          ==> usage
       U:type.exe -help       ==> help
       U:type.exe file(s)     ==> path to a file(s)

C:\test>U:type.exe -help
The C:\WINDOWS\System32\UnixTools\type.exe program will display the pa
+th to a file
if it is in the PATH environmental variable
[download]

If you have the same tool in your path, rename it (or just delete it. the 'which' command is better named and more useful) and the problem will go away.