On 04/08/2015 04:25 PM, Eric Blake wrote:
> I can beat it in an amortized way, by doing:
>
> f(){ false;}
> ${var+:} f
Or shorter:
f(){ eval "\${$1+:} [ ]";}
f var
>
> but only after I have at least 4 tests at 10 bytes each making up for
> the 12 bytes spent on the function definition (a longer function body of
> 'return 1;' instead of 'false;' guarantees no $? issue, but I already
> argued that no shell with functions has a false that returns other than
> 1). And while we are likely to have 4 or more instances replaced, my
> hack violates our shell function naming conventions (once we put it in
> the right as_fn_ namespace, direct use of false wins every time), not to
> mention legibility (hiding things in a function has its uses, but this
> does not seem to be one of them).
Here again, a function named 'as_fn_isset var' again loses out to the
more compact direct expansion, but at least this form is quite readable.
Likewise, the fact that it uses eval means that anyone passing a
non-variable name to the function deserves the chaos that ensues.
Of course, we can easily turn this thread into nerd sniping, if we
haven't already :) https://xkcd.com/356/
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
