urbanjost
commented
1 year ago M_CLI2 by default does not distinguish between "--" and "-" prefixes. It kicks into strict mode if ALL the options are long names with a single-character short name, which is specified like "set_args(' --one:o F --two:t F --three:T F'). That is if all the switches are defined as --LONG_NAME:LETTER then you can combine BOOLEAN single-character options. So if you had a program like
program demo9
!! long and short names using --LONGNAME:SHORTNAME
use M_CLI2, only : set_args, get_args, sget, rget, iget, lget
implicit none
call set_args('--length:l 1 --one:two:three F --height:h 10 --size:s 12.34567 --switch:X F --aa:a F --bb:b F --title:T "my title"')
write(*,*)'--length or -l is ',rget('length')
write(*,*)'--height or -h is ',rget('height')
write(*,*)'--size or -s is ',rget('size')
write(*,*)'--title or -T is ',sget('title')
write(*,*)'--switch or -X is ',lget('switch')
write(*,*)'--aa or -a is ',lget('aa')
write(*,*)'--bb or -b is ',lget('bb')
write(*,*)'--one ',lget('one')
end program demo9You could call it with "demo9 -Xa" and the booleans --switch and --aa would be true.
There are a lot of different approaches to the rules governing long and short options, bundling, and whether bundled short names can be anything other than booleans. Older programs had a variety of rules even before long switch formats existed and varied a lot. Some allowed only single-character switches, allowed them to be bundled, and allowed option values to appear in any order as well, others allowed long names and no bundling, some mixed that. So commands like "find" have a totally different syntax than commands like "ls" and "tar". Some commands expected the switches to be single characters and to come first with no dash. To this day most "tar" commands allow "tar xvfz name.tgz", for example. Several newer formats do not allow bundling, or only allow booleans to be bundled; some care about the prefix being "--" or "-" and others do not. Some require all options to have a long and short name. Some allow options to be numeric values, others do not. Some require values to always follow the keyword.
Never really decided which way M_CLI2 should behave, so never emphasized how it does work for bundling. But if all keywords have a long and short value "strict" mode kicks in, and booleans only can be bundled. There is a single sentence in the documentation that describes that but still wondering if it shoujld be changed.
M_CLI2 only allows the definition to provide a long name + colon + single-character short name, but originally instead of a short name the colon allowed giving a list of aliases, like " --one:two:three:four [value]." The idea, which was unique to M_CLI2 as far as I know, was mostly to allow key names in multiple languages but because a lot of Fortran compilers (particularly at that time) only supported basic ASCII characters, the number of languages supported was so limited it really did not pan out; so it was changed to support the LONG:SHORT syntax in the definition.
If the current behavior seems good, I will lock it in (and QA it, have not really used it that much); but open to creating a different behavior. Although it was originally intended that if bundling was supported, short and long prefixes would be enforced it is not rigorously enforcing that. I would probably change that to be strictly enforced when bundling was enabled.
M_CLI2 has always required values to follow the key they apply to, by the way. Not all parsers do, but all the most recent "standards" discourage the old behavior. Originally (and still, actually) Unix/Linux allowed a lot of syntax that is rarely mentioned any more (The command ">out ls" is just fine instead of "ls >out" for example, but you never see that documented) but argument parsing in particular varied and the few existing "standards" differ, but I think the M_CLI2 limitations about bundling are close to the current de-facto standard for recent applications.
From the docs it is unclear if short options may be bundled, e.g. -a -b specified as -ab.