[Top][All Lists]

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

[bug #47171] please fall back to system() when command is not found on $

From: Manoj Srivastava
Subject: [bug #47171] please fall back to system() when command is not found on $PATH
Date: Tue, 16 Feb 2016 20:34:38 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.103 Safari/537.36


                 Summary:  please fall back to system() when command is not
found on $PATH
                 Project: make
            Submitted by: srivasta
            Submitted on: Tue 16 Feb 2016 02:34:37 PM CST
                Severity: 3 - Normal
              Item Group: Enhancement
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
       Component Version: None
        Operating System: None
           Fixed Release: None
           Triage Status: None




This was reported by a debian user. Please retain a CC to 
so that the Debian BTS has a copy of your input. 

Trying the following makefile:

                command -v ls

I get the following result:

        $ make
        command -v ls
        make: command: Command not found
        make: *** [test] Error 127
        $ sh -c 'command -v ls'

but POSIX sayeth

| An execution line is built from the command line by removing 
| any prefix characters. Except as described under the at-sign 
| prefix, the execution line shall be written to the standard
| output, optionally preceded by a <tab>. The execution line |
| shall then be executed by a shell as if it were passed as the 
| argument to the system( ) interface, except that the shell −e 
| option shall also be in effect.

The cause is that "make" expects to be run on a POSIX system, where
non-special shell builtins like "command" would be available for use by execvp
(see sh_cmds[] in job.c).  See the explanation by Jilles Tjoelker at
for more details.

I can imagine two fixes, and both seem separately valuable:

 a. one hand hand, introducing a new package to provide those
    non-special builtins that are not provided by some
    pseudo-essential package (using alternatives to deal with 
    alternative implementations where necessary):

        command -p ${0##*/} "$@"

 b. on the other hand, teaching "make" to handle ENOENT from
    execvp by falling back to the shell.  (The shell can print a 
    message about it if that ENOENT was actually due to a 
    missing shared library or interpreter.)  This way, "make" 
    could even use shell builtins that are not mandated by POSIX 
    when the system shell happens to implement them.

This report is about (b).  Thoughts?



Reply to this item at:


  Message sent via/by Savannah

reply via email to

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