bug-inetutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Alfred M. Szmidt
Subject: Re: [bug-inetutils] Portability bug in inetutils src/Makefile
Date: Sat, 14 Jul 2018 17:07:14 -0400

   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?  Would something like,

             echo "WARNING: failed to install traceroute (exit code: $?)"

make better sense?

   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.  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)'`



reply via email to

[Prev in Thread] Current Thread [Next in Thread]