This wide- and large- screen layout may not work quite right without Javascript.

Maybe enable Javascript, then try again.

Home PC Administration

Forcing Command Line Arguments

Sometimes you'd like to force an application program to use some command line arguments (also called command line switches or command line options). For example you may prefer all executions of FireFox to include the -safe-mode command line argument. Unfortunately implementing such a thing in the Windows world is hard.

Problems Under Windows

If your users are cooperative and just want some way to get the right command line arguments without a lot of work, you can manipulate the properties of "shortcut" icons to supply the arguments. But if your users are not cooperative and look for ways to bypass your command line arguments, it unfortunately may be difficult to solve the problem on a vanilla Windows system.

There are many different ways to launch an application under Windows. And although you can apply your command line arguments to some of them, other ways allow your command line arguments to be circumvented. Each of the following methods of launching an application is amenable to adding command line arguments. (But the command line arguments must be added to each method separately - there is no shared method for remembering command line arguments.)

On the other hand, the following methods of launching an application in Windows have no provision for allowing you to even "suggest" command line arguments:

(Newer versions of Windows have a feature that goes by the generic name shim, which may be useful in some similar cases and may partially invalidate the statements above. The writer has no detailed experience with this feature, and does not know whether or in which cases the feature may be able to provide functionality similar to forcing command line arguments.)

Similar Solutions


Under *nix-like Operating Systems, forcing an application to use particular command line arguments is straightforward. Remove the permissions that allow the target users to launch the application directly. Then create a "shim" that can be launched by the target users which will in turn launch the application. (The shim is conventionally a *nix "shell script", which is very easy to create, debug, and modify.) Allow the target users to execute the shim, but not to modify it. Now the only way target users can launch the application is through the shim, which specifies the desired command line arguments and which the target users cannot modify.

As the special privileged user which the target users can't access, set the SETGID permissions bit on the "shim". When a target user executes the shim, it will internally change its identity to the Group of the special user that set up the shim, which then has the permissions to execute the desired application.

If a target user attempts to launch the application directly, they will be told "permission denied". If instead a target user launches the shim, it will in turn launch the desired application but only with the command line arguments the owner of the shim specified. If a target user attempts to modify the shim, they will be told "permission denied". And if a target user makes their own copy of the shim so they can modify it, it won't have the right permissions and won't be able to launch the desired application.

(One could do the same thing with the SETUID permissions bit, but this isn't recommended as it's more of a security risk than SETGID. In any case, to minimize security risk, the owner and group of the shim should be something other than "root" or the administrators main group.)

Windows-style Operating Systems have no analog of SETGID permissions, so this procedure is unfortunately not directly transferrable.


Forcing an application to use particular command line arguments could be done with some 16-bit DOS applications being run under Windows by specifying the desired command line arguments in a .PIF file. But it was too easy to circumvent that even for some 16-bit DOS applications, and it doesn't work with native Windows applications.

What To Do

To have most users most of the time use your command line arguments when launching an application, modify every one of these items:

  1. Shortcut in Start->Programs (if the application is installed per-machine -- otherwise it may be too hard)
  2. Shortcut icon on desktop
  3. Shortcut icon in taskbar (if it exists)
  4. BATch script files that launch the application (if they exist) (consider creating one if the application is frequently installed per-user rather than per-machine)

However this isn't even mildly tamper-proof. It's trivial in Windows to launch an application without using any of the mechanisms you modified above. It's quite possible a creative student/user will figure out how to bypass your command line arguments, then tell other students/users, and soon most of your student/user population will be bypassing your desired command line arguments.

If the application's altered behavior isn't very noticeable or annoying, you may be able to get by with this method. But if you can't tolerate any user ever bypassing your command line arguments, give it up and look for some other overall design instead. This information is very probably correct as of January 2006. But proving a negative is quite hard; there's always a small possibility this is incorrect.

Future Possibilities (Exercises for the Reader:-)

Theory suggests forcing a Windows application to use particular command line arguments may indeed be possible (but may not be easy enough to be included in an administrator's bag of reasonable tricks). The following are prime candidates for further investigation:

Location: (N) 42.67995, (W) -70.83761
 (North America> USA> Massachusetts> Boston Metro North> Ipswich)

Email comments to Chuck Kollars
Time: UTC-5 (USA Eastern Time Zone)
 (UTC-4 summertime --"daylight saving time")

Chuck Kollars headshot Chuck Kollars' other web presences include Chuck's books and Chuck's movies.

You may also wish to look at Dad's photo album.

All content on this Personal Website (including text, photographs, audio files, and any other original works), unless otherwise noted on individual webpages, are available to anyone for re-use (reproduction, modification, derivation, distribution, etc.) for any non-commercial purpose under a Creative Commons License.