However, it has a precondition that developers MUST respect:
An option CAN'T have differente meanings/behaviour in different subcommands.
For example, "-s" means "size" and accept an argument. If you are tempted to add
an option "-s" (that means, for example "silent", and doesn't accept an argument)
This, however, make sense even from an usability point of view.
Also, option with optional argument are prohibited.
The technique is a "double scan": first, we scan options passing
_every_ possible subcommand options to zparseopts.
This way, we can distinguish between option argument and parameters.
So, we recognize which is the subcommand.
Then, parse again
It was putting the option BEFORE the subcommand.
However, the new method supports this only partially:
* Boolean options can be put before the subcommand
* Subcommand-specific options that take an argument can be put before the
subcommand, only in the
form -kvalue ; using -k value gives an error
* Global options can always be put before the subcommand
Therefore, we'll say that options MUST go after the subcommand (to stay sure)
* parameters can be added where you want
* it's possible to use long options
* you can have "synonim" options
* it has potential for a recursive implementation
and notice if tomb hasn't right permissions
in future we should check permissions of tomb from the suid commandline
this way we can also change its permissions and make it ours
now the internal command tomb translate
generates a list of strings used inside tomb ready for translation
(as a .po file)
help needed: translations and autotools integration
