Command Line Arguments

With Command Line Arguments it is important to remember that the program running on the operating system is fglrun .  You effectively have two sets of command line arguments.  There are the arguments that apply to fglrun (what you see in the various tables here), and those that apply to your program, those that are listed after the program (.42r or .42m) name.

One way to think of it is that with fglrun [exec-options] program [ argument [...] ], the exec-options belong to Four Js, argument belongs to you.

What belongs to fglrun appears after fglrun, what belongs to your program appears after your program.

Reading Command Line Arguments

There are three ways to read what arguments have been passed into your Genero program.

arg_val function

The arg_val function is what was in Informix-4gl.   arg_val(1) returns the first argument, arg_val(2) returns the second argument etc.

What is also interesting is that arg_val(0) returns the name of the program.  If you think about it, after the exec-options, program is the 0’th argument of fglrun.

You may see code of the pattern OPEN WINDOW w WITH FORM arg_val(0) and what it s doing is loading a form that has the same name as the program.

The num_args function was also in Informix 4gl and tells you the number of arguments that were passed.

base.Application methods

When Genero was introduced, a number of methods were added in the base.Application class that provides a set of utility functions related to the program and its environment.

These included base.Application.getArgument() and base.Application.getArgumentCount() that are the equivalent of arg_val() and num_args().  I am not aware of any difference in functionality between the two sets of arguments.  The advantage of class and methods is that they appear in code completion and real time syntax checking.

When these were introduced in the early 2000’s, I thought Four Js might have extended these with more functionality and I wrote some library functions that you can see here that extend these.  My thinking being that one day when Four Js added equivalents I could simply go 1,$s/getArgumentExists/base.Application.getArgumentExists/g over my code base.  That day has not arrived yet…

getopt module

What Four Js instead implemented in 3.20 was the getopt command line options module which is similar to the getopt c library function.  If you study the Usage you will see that it is intended to be used at or near the beginning of your program.  A WHILE loop processes the options passed and sets variables so that your program operates as per what the command line arguments are indicating.

What it also does is via the invalidOptionsSeen() method allow you to capture cases where an unknown option is used or a required option is not present.  You can stop the program at the beginning.

It also has a displayUsage() method so that you can output to stdout/stderr a useful message if someone tries to run your Genero application with missing or invalid arguments.  You can also configure it so that this method will also be called if -h or –help argument is used.

If you have not explored the getopt module I would encourage you to do so.   It does encourage you to follow conventions

Also if you look in FGLDIR/src you will find getopt.4gl and in FGLDIR/lib you will find getopt.42m.  You can tweak and override it if you wish.

Passing Command Line Arguments

At the command line

As mentioned at the beginning, the key thing to remember is that your arguments go after the program name.   Assuming you are trying to pass --mode update as your command line arguments, it is fglrun program.42r --mode update, not fglrun --mode update program.42r

Similarly if trying to use fglrun arguments, they go between fglrun and the program.  Assuming you are trying to pass -p to use the profiler, it is fglrun -p program, not fglrun program -p.

Using getopt library can help detect an unexpected command line argument or a mandatory command line argument missing.

via Genero Application Server

When running programs via Genero Application Server, deep down via the EXECUTION COMPONENT you are building up a command to execute on the command line.

If the command line argument is implied via the link you are clicking on, or the via the base of the URL typed, then you can use the PARAMETERS element to indicate the command line arguments.  These will then be appended after the DVM and MODULE to the command line that is built.  The command line is effectively DVM MODULE PARAMETERS.

URLs also allow you to specify a query string by passing parameters after a ?.  These are by default not added to the command that is executed unless you explicitly allow it by specifying allowUrlParameters=TRUE in the EXECUTION tag.  Each separate argument is indicated by Arg= in the URL as per this entry in the documentation.

So with the fglrun program.42m –mode update from above, this might be achieved by either having these in the .xcf
<PARAMETER>--mode</PARAMETER>
<PARAMETER>update</PARAMETER>

and a URL of

http://webserver/ua/r/program

or no PARAMETER in the .xcf, AllowUrlParameters=TRUE in the .xcf

and a URL of

http://webserver/ua/r/program?Arg=--mode&Arg=update

Usage

Final point I will make is that a well designed program can use command line arguments todo many things.  For example a well designed QAUD program could use command line arguments to have a read-only mode, to add a new record, to update an existing record, to view an existing record simply by passing command line arguments that enable/disable actions and populate fields.