The CL.EXE Command Line

The compiler receives its first directions from the user as text, primarily from the command line, but also from files and environment variables. This text is parsed into tokens, which are typically referred to as command-line tokens even when drawn from other sources. Tokens are separated by white space in general, but the command-line parsing does have several special cases. A quick summary is that: white space is allowed within a token if enclosed by double-quotes; the support for double-quotes has consequences for interpreting backslashes; and tokens that contain wildcard characters * and ? may be subjected to wildcard expansion.


Each command-line directive consists of one or more whole tokens. Three general categories are recognised:

There is some mixing of the various types of directive. As suggested already, a directive that names a command file may in turn provide more directives of each sort, including to name more command files. It is also provided that input files can be named by options (specifically, by /Tc, /To and /Tp).


The compiler finds its directives on an effective command line composed from the following sources in the following order:

with the understanding that in each of these sources, each token that names a command file is replaced by the text from that file. Each of the sources, and each line from a command file, is parsed independently. This means in particular that no token can carry over to the next of these sources or to another line, and neither can any option that is otherwise permitted to spread to subsequent tokens.

Only in very few cases does it matter whether an instruction to the compiler has been drawn from one source or another. It is the standard practice of these notes that all references to the command line, unless qualified as the actual command line, mean an effective command line composed as above.

Strictly speaking, the command line as composed above is just what can be supplied by the user. It is as well to be aware that CL may draw upon two hard-coded command-line contributions. One precedes the user-supplied command line and acts to set initial options which the user is free to override. Indeed, if a user-supplied option overrides or is incompatible with an initial option, then the initial option is discarded silently. Otherwise, the initial option persists by default. The other case applies after the user-supplied command line and acts to ensure that compulsory options are set even if neglected by the user.

While noting exceptional cases, it is as well to mention that the command line receives both an ordinary processing, as described above, and an early pass. The latter is a quick scan, mostly to decide a few points of behaviour for the ordinary processing and for such things as the startup logo that are attended to before any substantial work begins. The early pass affects only a handful of options (/Be, /clr, /nologo, /noover and /ZX), and in some cases only very slightly.


After expansion of command files, each directive names an input file directly, or is an option that names an input file indirectly, or is any other option. Directives that name input files, directly or not, build a list of input files. When adding input files to the list, CL does not check for repetitions. Directives that do not name input files build a list of options. When adding options, CL checks for duplicates (except of /I options), overrides, incompatibilities and prerequisites. The two lists, of input files and of options, are essentially separate. All the options apply to all the input files. No record is kept of the ordering of options relative to directives that name input files. However, intermingling may attract a warning (D4026), specifically for the first occurrence of an option between two directives that name input files.