The general syntax of the `polymake` command line is described in the User's Guide Introduction. Here only the more exotic options, or those applicable to various running modes, are described.

### Special running modes

--help
Print the brief description of command line arguments and exit.
--version
Print the version number and copyright notice, then exit.
--verify FILE {PROPERTY | LABEL} ...
This is the command line analogon to the Poly::Object::verify method call. In the successful case nothing is printed, unless verbose mode is on. The data file remains unchanged.
--touch FILE ...
Read the specified data files, write them back to the disk, and exit. This operation makes sense after a version upgrade, since it can incur a change of file format. By the way, `polymake` always automatically converts data files to the up-to-date format, so you will need this option only if you want to update a large collection of data files at once.

### Options applicable to other running modes

--reconfigure
Repeat the autoconfiguration routines in all rulefiles, re-read the shared (system-wide) configuration file. The custom variables without CONFIGURE: labels are, however, immune to whatever changes.
You will need to use this option once you (or your sysadmin) have installed some lacking external software `polymake` has complained about.
--reconfigure-rules RULENAME ...
Repeat the autoconfiguration routines in the selected rulefiles. Each RULENAME can be a name of a rulefile (omitting the .rules suffix is allowed), a shell-like filename pattern or a perl regular expression.
Use this option as soon you have installed some lacking software package(s). Other rulefiles will keep the settings obtained earlier, thus saving your time.
--keep-temporary
Ignore the temporary attribute in the property declarations. The temporary properties are not removed from the input files, and those later created are stored together with persistent properties. This options is introduced solely for debugging purposes.
-T timeout
Set the time limit (in seconds) for the execution of production rules. A rule exceeding this limit will be interrupted and treated as failed. Default policy is to let all rules run as long as necessary.
Note that unlike the standard system ulimit cputime , timeout is the amount of time measured by the wall clock time and not the time really consumed by the CPU.
-n
"dry run" mode: `polymake` determines the rules it would have to execute in order to get all requested properties. It then prints the rule headers in the execution order and the sum weight, and exits without computing anything.
Note that the rule chain displayed here can deviate from the one applied in a real case as soon as preconditions and dynamic rule weights are involved. The reason is that in the dry run mode the rule execution is inhibited, therefore `polymake` simply assumes all preconditions to hold and all dynamic weight components to be equal zero. Naturally, if some assumption happens to fail later, then different rules must be chosen.
This option is applicable only in the compatibility and --verify modes.
-v
Increase the verbosity level. This option may be repeated several times, enabling more and more warnings and informational messages to be printed to STDERR.

1. Display the version number. Warn about undeclared properties. Warn about overwritten data files. Tell about failed preconditions of production rules. Report successful comparison of properties in --verify mode.
   Some user functions also produce more output.
2. Show the names of loaded rulefiles. Tell about production rules and synchronization routines being applied.
3. Comment the rule planning procedure in details: tell about satisfied preconditions, applicable, preferred, and infeasible production rules.

-d
Enables some internal assertions and printing debugging output to STDERR. This option may be repeated several times.

1. Show the command lines of clients and external programs started from within the rules. Show the requests sent by clients.
   Keep the temporary files created by Poly::Tempfile in the case of the rule failure.
   The verbosity level is automatically increased to 2.
2. Debugging output from the rule scheduler. Show the communication between `polymake` and interactive JavaView components.
3. Exhaustive dump of the rule scheduler internal structures.
4. Show the transformed rulefiles after parsing.

### Deprecated options

The following options are still supported for the sake of compatibility with previous versions, but there are now better alternatives. The warning messages issued each time one of these options is used should motivate you to migrate by the first occasion.

-f RULEFILE
Load the specified rulefile additionally to the standard rule file main.rules. This is a deviation from the earlier `polymake` versions, where the specified rulefiles were loaded instead of the standard one, which was formerly called poly.rules. May be repeated several times.
This option has been made deprecated since it does not allow to specify which application the rulefile belongs to. The better solution is to use include commands in the preference file ~/.polymake/prefer.pl.
-I DIRECTORY
Specify a directory where `polymake` should seek for the rulefiles, applications, and scripts. May be repeated several times.
The preference file ~/.polymake/prefer.pl contains several variables (arrays) which should be used instead of this option.
-A APPLICATION
Let `polymake` assume that the data files belong to the specified application. Since all construction functions put the application name automatically, you will only need this option for manually created files.
This option affects all files read by `polymake`, therefore is not much suitable for the scripting mode. The better way is to specify the application name in the data file from the very beginning.
Another effect of this option is to restrict the set of applications loaded initially to the given one. The more flexible way is to list your favorite applications in a custom variable @main::FavoriteApps.

The use of the environment variable POLYMAKE_SWITCHES for storing the options permanently is deprecated too, since all alternative solutions involve the private customization files. This variable is still sometimes needed to pass debugging options to the `polymake` script when it is started by a client program, but this becomes unneeded as soon as the clients are converted to real subroutines.