Printable View
Hi all. I'm using getopt_long_only() in a project and I'd like to able to use it in a case insensitive manner. I've done a fair bit of googling on the subject but I can't find a thing. As a hack I could just lower the case of the command line string prior to processing, but if I could manage it in a more graceful way that would be preferable. A portable stand-alone command line parser (preferably similar to getopt) that permits this would also be good. Any help is appreciated. Thanks, Ehtyar.
Well if searching the manual revealed nothing about case insenstive behaviour, I'd go with your backup plan.
At least anyone reading the code would instantly see what was going on.
A problem I didn't foresee is file names on the command line in Linux. I may just be better off finding a 3rd party getopt library and modifying it. Ehtyar.
How about posting what you got.
First of all, I'm pretty sure there is a GNU getopt implementation somewhere.
Second, do you really need a fully case-insensitive option getter, or just support the common cases:
Option
option
OPTION
rather than supporting for example
OpTiOn
opTIon
and other very unlikely combinations.
If the former, perhaps writing a piece of code for the setup of getopt to produce the three or so variants that are likely from a base-configuration (what I'm trying to say is to just produce the variants that make sense with code that does toupper in suitable places).
That is not as "nice" as something that allows just about any combination, but in honesty, how many people would grumble if -OptIoN doesn't work?
--
Mats
--
Mats
You will have to simply code for the case. Using a 'switch case' for your options for both the lower case and upper case and the logic will just fall threw just do not call a break in between the options.
Research the switch statement if you are not familiar with this.
But that is not how getopt works.Quote:
Originally Posted by slingerland3g
--
Mats
I do agree that it is unlikely that switches will be specified in mixed case, though the duplication as was mentioned would lead to easily 150 different switches to process. I'd really just prefer case insensitivity.
I'm going to pull the getopt implementation from MinGW and see how portable it is. If it's all good then I'll modify it and use it in my project.
Otherwise, I think I may just end up including a warning in the documentation and leave it at that.
Thanks for the replies thus far, Ehtyar.
But as long as the usage isn't listing 3 of each option, what is the problem with having 150 switches generated from the original 50 switches - all it takes is a little bit of coding (probably about 5 lines or so) to generate the longer version of the input table to getopt.Quote:
Originally Posted by Ehtyar
Generating variants of the same thing is something computers are pretty darn good at. 150 options does not take up much space in a modern system, and if you have 50 or so options, I expect you aren't dealing with some program that runs on a microcontroller where a few kilobytes of memory makes a huge difference.
Of course, the choice is yours, I'm just suggesting "an easy solution" that doesn't involve changing some rather complicated, existing and working code.
--
Mats
Well, after examining the getopt.c from MinGW (was too windows-specific) and trying various others found on the net (more bugs than I'd care to have in a bug zapper) I've decided to go with the warning in the readme and leave it at that. I expect there will be the odd issue, but as long as I print errors for unknown switches things should go OK.
Thanks for all the help guys, much appreciated.
Ehtyar.
That is obviously another "easy" solution. And most people will be able to learn that options are given as lower-case or upper-case only, and live with it.Quote:
Originally Posted by Ehtyar
--
Mats