getopts: not setting OPTARG when argument is both long form and declared optional

[rosswmerrifield]

I am trying to use getopts in my script, but I would like to use both long forms of arguments as well as making some arguments have optional values.

here is a script that works as expected (% is my shell prompt), the option has short and long versions but it is mandatory

% cat opt-test-1.ksh                                                          
#!/usr/bin/env ksh93
 
USAGE="[+NAME?opt-test-1.ksh ]" 
USAGE+="[m:max]#[max_hours:=24?Get the max value in the past x hours.]" 

while getopts "$USAGE" optchar ; do 
  case $optchar 
    in 
      m)  print "OPTARG: $OPTARG" ;;
  esac 
done
% 
% ./opt-test-1.ksh -m 10                                                      
OPTARG: 10
% ./opt-test-1.ksh --max 10
OPTARG: 10
% ./opt-test-1.ksh --max   
./opt-test-1.ksh: --max: numeric max_hours value expected
Usage: ./opt-test-1.ksh [-m max_hours]
 Help: ./opt-test-1.ksh [ --help | --man ] 2>&1
% 

However, when I change the script to make the argument optional (note the inserted ? character), OPTARG does not get set when the long form of the argument is used

% cat opt-test-2.ksh 
#!/usr/bin/env ksh93
 
USAGE="[+NAME?opt-test-2.ksh ]" 
USAGE+="[m:max]#?[max_hours:=24?Get the max value in the past x hours.]" 

while getopts "$USAGE" optchar ; do 
  case $optchar 
    in 
      m)  print "OPTARG: $OPTARG" ;;
  esac 
done% 
% ./opt-test-2.ksh -m 10
OPTARG: 10
% ./opt-test-2.ksh --max 10
OPTARG: 
% ./opt-test-2.ksh --max   
OPTARG: 
% 

[rosswmerrifield]

Forgot the mention, version is Version AJM 93u+m/1.0.7 2023-09-15. I have the same issue on 1.0.6

[jghub]

./opt-test-2.ksh --man should tell you that the syntax for long options (always: this has nothing to do with optional vs. mandatory argument) is

./opt-test-2.ksh --max=10

and then it should work, no?

[McDutchie]

Yes, that's it. Strictly, in the GNU long option syntax, you need the = to add an option-argument. The whole long option plus its argument needs to be one word.

There are also programs that don't require the = and take the next separate word as the option-argument instead, and it looks like the AT&T developers decided to support that syntax as well.

But that is incompatible with the argument being optional. If it is optional, there is no way to distinguish between --max 10 where 10 is an option-argument to max, and --max 10 where --max does not have an option-argument and 10 is simply a separate, non-option argument. So that is why the = is necessary in that case.

IMHO it would have been better if ksh never supported the =-less variant in the first place (for normal mandatory option-arguments), as that would have kept the situation consistent. But that is not something we can change at this point, as it would break backward compatibility.

[rosswmerrifield]

Yes, adding the = character to the long argument works as expected. It makes sense why it works this way in retrospect. Is there any interest in contributions of some examples to the wiki in this repo? getopts --man is pretty terse

[McDutchie]

Since this is not a bug, I've converted the issue to a discussion thread. That way, it can stay visible for future reference, instead of simply closing the issue.

Yes, I would absolutely be interested in contributions of examples. Please feel free to edit the wiki. I may use some of it for future documentation in the distro. Thanks :)