On 11 February 2012 14:04, Christoph Lohmann <2...@r-36.net> wrote:
> Anselm R Garbe wrote:
>> However the real point is that the getopt() style or ARGBEGIN crap
>> enables and encourages the developer to introduce a bad command flag
>> interface. Because those approaches hide the utter complexity
>> involved, the developer tends to care less here. This is my main
>> argument against getopt() or ARGBEGIN.
>>
>> If you can write a simple for() loop to process your command line
>> flags, your interface can't be that hard to grasp for the user.
>> Otherwise he will look up the weirdo flags quite often in your man
>> file and develop hate against your tool over time ;)
>
> That is plain wrong. The ARGBEGIN { } ARGEND; style is easy to read
> and adds all the convenience you want in flag parsing. On the other
> side getopt() adds a huge dependency.Well, I agree that ARG... is simpler than getopt(), but that's beside the whole point. Usually the ARG.. handling can be done very similar just using a for() loop, in most cases. And in all other cases you should rather reconsider your whole command line interface, as this indicates bad design or too much choice already. > The suckless standard library should include either the ARG* macros > or add another function, which can be put into the switch() state- > ment. I really can't see that need. > Users will rather be irritated, if the commandline argument hand- > ling is different in every application. They then *have* to read > the sourcecode for finding out how arguments are handled. It's quite consistent in most suckless tools actually. One difference I stumbled upon is exactly stest, because it uses the clunky getopt() approach and I really wonder why it needs so many flags. Cheers, Anselm
