[PATCH] Add namespaces support to rlFile{Backup,Restore}

Jiri Jaburek jjaburek at redhat.com
Wed Oct 24 08:31:21 UTC 2012


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 at 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



More information about the beakerlib-devel mailing list