On 09/08/17 07:55, Илья Шипицин wrote:
>     >     For example:
>     >
>     >     $ ./openvpn --help | grep -- ^-- | wc -l
>     >     238
>     But to do the spoon feeding:
>     optcount="$(${top_builddir}/src/openvpn/openvpn --help | grep -E --
>     ^-- | wc -l)"
>     if [ $outcount -lt 220 ];
>     then
>             exit_code=1
>     fi
> if you suggest "that's a better check", please describe your idea.
> it is not clear for me why your approach is better

The approach I suggest above covers:

a)  The program is able to execute and usage() works

b)  There is no unexpected bigger changes in usage(), the
    number of options are within a reasonable threshold.
    Granted, only minimum options is checked in the example above;
    extending with an upper limit is easy and quick (for example
    add '-o -gt 245')

c) If the program segfaults, optcount => 0 which ensures this test

With your check only testing if the exit code is not 1, you only have an
indication if the program segfaults or not.  You don't know if usage()
provides nothing but garbage and then exiting with 1.  Checking that a
certain amount of outputted lines starting with '--' gives an indication
that usage() most likely have a reasonable output.

It would also be possible to build further on this check I suggest, to
also check for mandatory options (--dev, --dev-type, --remote, --listen,
--port, --proto, etc, etc).  It is also possible to have a copy of the
expected "openvpn --help | grep -E -- ^--" output and do a diff -
probably filter out some less important/deprecated options).   While
these are a nice checks too, it is not as crucial as ensuring we have at
least an reasonable expected amount of options.

kind regards,

David Sommerseth
OpenVPN Technologies, Inc

Attachment: signature.asc
Description: OpenPGP digital signature

Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Openvpn-devel mailing list

Reply via email to