On 10/23/2012 06:16 PM, Roman Rakus wrote:
On 10/23/2012 05:35 PM, Jiri Jaburek wrote:
> This change introduces a new --namespace option for rlFileBackup
> and rlFileRestore, allowing the user to perform several backup/restore
> operations independently.
>
> Getopt might seem like an overkill, but there's no primitive and safe
> way of using multiple long options with arguments without it.
> Also while rlFileRestore could get away without it (no --clean),
> I believe it's important to keep a certain level of consistency.
Hi,
at first I have to state that I have no experience with getopt.
But, I have found one wiki page full of very good informations about
shell scripting and there is also a page about parameter parsing:
http://mywiki.wooledge.org/BashFAQ/035
I didn't test your patch, maybe it is working, but I recommend to follow
the wiki and don't use getopt instead use getopts.
From my first view, using getopt looks like nasty hack. But in the end,
parsing arguments in shell is really kind of PITA.
RR
_______________________________________________
beakerlib-devel mailing list
beakerlib-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/beakerlib-devel
I have tested it very thoroughly, manually, using automated test
runs in Beaker and by executing the bundled test "suite".
I've chosen getopt, because there's AFAIK no long options support
in getopts. There's also no GNU-C-like getopt_long in Bash.
Even the linked wiki states:
"The disadvantage of getopts is that it can only handle short options
(-h, not --help) without trickery."
and that "trickery" (also described on the wiki) seemed much more of
a hack to me.
Forcibly using getopts instead of getopt makes sense when we want
the code to be portable (ie. not GNU/Linux-only).
Jiri