I understand that theory, but it doesn't appear to work. Here is the full contents of the Dominions3 directory, including hidden files:
Quote:
/Applications/Games/Dominions 3$ ls -al
total 24
drwxr-xr-x 7 psientist admin 238 Jan 9 16:37 .
drwxr-xr-x 7 psientist admin 238 Jan 1 19:18 ..
-rw-r--r-- 1 psientist admin 6148 Jan 9 16:37 .DS_Store
drwxr-xr-x 3 psientist admin 102 Aug 29 14:46 Dominions3.app
dr-xr-xr-x 5 psientist admin 170 Aug 29 14:46 doc
|
The problem is that OSX is also throwing an error; the application never runs the command switch at all:
Quote:
/Applications/Games/Dominions 3$ open Dominions3.app -h
2007-01-14 14:51:33.735 open[4128] No such file: /Applications/Games/Dominions 3/-h
|
Now, we can try to be more savvy, and open up the OSX Dominion3.app executable (which is actually a directory bundle), and navigate to the application's core MacOS resource:
Quote:
cd Dominions3.app/Contents/MacOS
|
but the core executable there throws the exact same error:
Quote:
/Applications/Games/Dominions 3/Dominions3.app/Contents/MacOS$ open Dominions3 -h
2007-01-14 14:54:21.612 open[4132] No such file: /Applications/Games/Dominions 3/Dominions3.app/Contents/MacOS/-h
|
So apparently neither the Windows nor the MacOS command lines are behaving the way you expect. In fact, it *looks* like the Doms3 app is interpreting the "-h" flag as a filename argument, based upon the error response.