Difference between revisions of "Command line parameters and environment variables"

From Free Pascal wiki
Jump to navigationJump to search
(→‎Checking parameters for validity: wikified link to docs.)
Line 83: Line 83:
 
=== Checking parameters for validity ===
 
=== Checking parameters for validity ===
  
Command line parameters are free text, so the user can easily do typing errors. Checking the syntax of the parameters is therefore mandatory. You can use the [http://www.freepascal.org/docs-html/fcl/custapp/tcustomapplication.checkoptions.html CheckOptions] method for this:
+
Command line parameters are free text, so the user can easily do typing errors. Checking the syntax of the parameters is therefore mandatory. You can use the [[doc:fcl/custapp/tcustomapplication.checkoptions.html|CheckOptions]] method for this:
  
 
You can define, what parameters are allowed, which ones ones need a parameter and in case of a syntax error you can get an error message plus the options that were wrong to print helpful and detailed errors.
 
You can define, what parameters are allowed, which ones ones need a parameter and in case of a syntax error you can get an error message plus the options that were wrong to print helpful and detailed errors.

Revision as of 23:20, 29 May 2008

Overview

When a program is started a user can give command line parameters and setup environment variables. For example the FreePascal compiler gets most of its parameters via command line options:

 fpc -Fudirectory -gh unit1.pas

Command line parameters - the basics

A pascal program can access the parameters via ParamStr and ParamCount. ParamStr(0) is the program path itself. ParamStr(1) is the first parameter. ParamCount is the number of parameters.

<DELPHI> program Project1;

{$mode objfpc}{$H+}

var

 i: Integer;

begin

 writeln('Program: ',ParamStr(0));
 for i:=1 to ParamCount do
   writeln('Param ',i,': ',ParamStr(i));

end. </DELPHI>

For example:

 $ /tmp/project1 -a
 Program: /tmp/project1
 Param 1: -a

Command line parameters - comfortable

A good program should give a help message when invoked with the wrong parameters and it should follow a common way of giving parameters. The unit custapp that comes with FPC provides the TCustomApplication class, which provides functions to easily check and read parameters. Of course you can still access the parameters directly via ParamStr and ParamCount.

Every LCL application uses this automatically. The Application object is a TCustomApplication.

If you want to write a non LCL program, then create in lazarus a new project of type 'Console Application'. This will create a project1.lpr with some nice goodies, that almost all programs need. Go to the DoRun method.

Check for a parameter

With TCustomApplication you can access parameters by name. For example your program should print a help text when the user gave the common help parameter -h. The -h is a short option. The long form is the --help. To test whether the user called the program with -h or --help you can use <DELPHI> if HasOption('h','help') then begin

 WriteHelp;
 Halt;

end; </DELPHI>

Note: In an LCL form you must prepend Application. in front of HasOption. For example:

<DELPHI> if Application.HasOption('h','help') then begin

 WriteHelp;
 Halt;

end; </DELPHI>


<DELPHI> // If you only want to support the short option use: if HasOption('h',) then ...

// If you only want to support the long option use: if HasOption('help') then ... </DELPHI>

Read the parameter value

Each parameter can be given a value. For example:

 project1 -f filename

or with the long form:

 project1 --file=filename

<DELPHI>

 writeln('f=',GetOptionValue('f','file'));

</DELPHI>

Note: if you get the error message Option at position 1 needs an argument : f. then you forgot to add the option in the CheckOptions call.

Checking parameters for validity

Command line parameters are free text, so the user can easily do typing errors. Checking the syntax of the parameters is therefore mandatory. You can use the CheckOptions method for this:

You can define, what parameters are allowed, which ones ones need a parameter and in case of a syntax error you can get an error message plus the options that were wrong to print helpful and detailed errors.

Examples: <DELPHI> ErrorMsg:=CheckOptions('hf:','help file:'); </DELPHI>

This allows passing short options -f value and -h. It allows passing long options --help or --file=filename. It does not allow --help with a value, nor --file without a value.