[Gambas-user] a command line with arguments to parsed program?

[PICCORO McKAY Lenz]

El mié., 16 de oct. de 2019 a la(s) 03:44, Bruce (adamnt42 at gmail.com) escribió:
> Why is this important? Because the native Args class provided by the
> "gb" component considers the whole command line as a space delimited
> list of ARGUMENTS (no OPTIONS handling is done and it would be up to the
> program code to decipher each token and decide what it is and how to
> work with it.

Oh Finally! someone who had common sense... was just thinking about
the difference between the two cases... that's why I was asking for
the example... I see that the class itself is very basic from the
point of view of documentation.

>So hopefully now we are clear on the difference between OPTIONS and
> ARGUMENTS.

always was CLEAR.. the problem it's the implementation, you mail are
pure GOLD  Bruce... must be parsed as a tutorial in the gambas wiki!
Many many thanks!

>         $debugLevel = Args.GetInteger("d", "debug", "The program will output
> lotsheaps or tins of debugging information to the terminal", "level", 1)
>
> With this, if the user species the -d/--debug <int> pair on the command
> line the $debugLevel value will be set to that value. (if they only
> provide the option without a value then it will be set to 1 - automagically!
>
> The -h output will now look like:
>
> mygbproject
> ===========
>
> My brilliant Gambas project
>
> Usage: mygbproject <options>
>
> Options:
>
>   -d --debug <level>     The program will output lots or heaps or tons
> of debugging information to the terminal (default=1)
>   -V --Version                   Display version
>   -h --help                      Display this help
>
> Hmm, we can do better than that! Is 1 equal to "lots" or "tons"?




>
> Lets try a string value option:
>
>         $debugLevelStr = Args.Get("d", "debug", "The program will output lots
> (L) or heaps (H) or tons (T) of debugging information to the terminal",
> "level")
>
> If present then the $debugLevelStr value will be set to the value
> provided (NOTE! the gb.args Args.Get() function does NOT provide a
> default value!). And the -h output will look like:
>
> mygbproject
> ===========
>
> My brilliant Gambas project
>
> Usage: mygbproject <options>
>
> Options:
>
>   -d --debug <level>     The program will output lots (L) or heaps (H)
> or tons (T) of debugging information to the terminal
>   -V --Version                   Display version
>   -h --help                      Display this help
>
>
> Args.GetFloat() acts similarly to Args,GetInteger.
>
> Now there is only one thing left, the Args.End() call. This handles the
> program ARGUMENTS exactly as specified in the help page, So,
>
>         $myArgs = Args.End()
>
> It would be usual to indicate the ARGUMENTS in the usage header
> indicating whether they are optional and whether multiple values are
> handled. Say we need one or more file names as ARGUMENTS. Then something
> like
>
> mygbproject
> ===========
>
> My brilliant Gambas project
>
> Usage: mygbproject <options> [filename]...
>
> Options:
>
>   -d --debug <level>     The program will output lots (L) or heaps (H)
> or tons
>   (T) of debugging information to the terminal
>   - -- <<new>>
>   -V --Version                   Display version
>   -h --help                      Display this help
>
> would be appropriate.
>
> I think that's about the simplest I can put it.  When you consider the
> amount of code you would have to write to handle the above using the
> simple gb Args class, it's quite amazing actually.
>
> hth
> bruce
>
> ----[ Gambas mailing-list is hosted by https://www.hostsharing.net ]----