Re: [bug-inetutils] Portability bug in inetutils src/Makefile

[Bill Cole]

On 14 Jul 2018, at 17:07 (-0400), Alfred M. Szmidt wrote:

>    The various install-*-hook targets are of the form shown here for 
> traceroute:
>
>    install-traceroute-hook:
>          address@hidden(INSTALL_PROGRAM) traceroute $(SUIDMODE) 
> $(AM_INSTALL_PROGRAM_FLAGS) $(DESTDIR)$(bindir)/`echo traceroute|sed 
> '$(transform)'` ; \
>          if test $$? -ne 0; then \
>            echo "WARNING: insufficient access; not installing traceroute"; \
>            echo "NOTE: To install traceroute run 'make install' as root"; \
>          fi
>
>    This has 2 significant flaws:
>
>    1. The error warning assumes that the only failure mode is
>       insufficient access. This is an incorrect assumption. Most
>       obviously, incorrect invocations are possible. While the GNU
>       'install' appears to use '1' as the exit code for all failures,
>       others (e.g. BSD install) provide useful distinctions in their
>       exit codes which could be exposed to the user rather than
>       assuming that all failures are identical.
>
> This is just a warning (not an error); a better message might make
> more sense.  Does BSD install return non-zero on failure to copy the
> binary?

Yes. 64 (usage), 71 (file non-existence), and 77 (permissions) are all possible

> Would something like,
>
>            echo "WARNING: failed to install traceroute (exit code: $?)"
>
> make better sense?

Yes.

>    2. GNU 'install' tolerates the idiosyncratic argument ordering used
>       in the Makefile (putting options between the source and target)
>       but this is undocumented behavior and is NOT consistent with BSD
>       'install' which fails with an exit code 64 (EX_USAGE) when given
>       that syntax. This could in principle be addressed at configure
>       time by testing the install binary or simply by making GNU
>       install a dependency, but the simplest approach would be to use
>       the compatible documented calling order, like this:
>
> This is neither idiosyncratic or undocumented, this is the standard
> behaviour for getopt_long and all GNU programs.

Thank you for that fact! I vaguely knew that GNU programs tended to handle 
arbitrary command-line argument ordering more flexibly, but was not aware that 
it was grounded in the getopt_long implementation. It is always good news to 
know that I have more to learn .

> I don't see harm in
> the change though so things to work smoothly on BSD too.
>
>          address@hidden(INSTALL_PROGRAM) $(SUIDMODE) 
> $(AM_INSTALL_PROGRAM_FLAGS) traceroute $(DESTDIR)$(bindir)/`echo 
> traceroute|sed '$(transform)'`

Thank you for your help.

-- 
Bill Cole
address@hidden or address@hidden
(AKA @grumpybozo and many address@hidden addresses)
Currently Seeking Steadier Work: https://linkedin.com/in/billcole

signature.asc
Description: OpenPGP digital signature