tech-toolchain archive

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

Re: make (was: Re: re: release failure with relative path)

At Fri, 26 Mar 2010 08:21:08 +0200, Alan Barrett <> 
Subject: Re: make (was: Re: re: release failure with relative path)
> On Thu, 25 Mar 2010, David Holland wrote:
> > On a related matter, can anyone think of any reason why make shouldn't
> > absolutize its path to itself?
> Do you mean, when you run "./make", that you want it to set ${MAKE}
> to "/some/absolute/path/make"?  That seems like a good idea.  On the
> other hand, when you just run "make" and the shell or kernel finds
> /usr/bin/make by searching the PATH, it seems reasonable to leave
> ${MAKE} set to just "make", not to "/usr/bin/make".  I suppose it could
> distinguish between the two cases by looking for a slash.

Esthetically you may be right, i.e. it might "look" nicer for the
program to simply retain the form of the command name that the user
started it out with and to continue to rely on $PATH for finding itself
again when it recursively calls upon itself.

However from a hygienic and reliability standpoint it might be safer
indeed if the program always fully qualifies the path of its own argv[0]
before running itself recursively again, especially since with this
particular program (make) its input can easily change its own
environment in subsequent invocations and sometimes in non-intuitive

(BTW, to be pedantic, I don't think the kernel ever searches $PATH --
that's done in the library function front-ends to the execve(2) system
call.  :-))

                                                Greg A. Woods
                                                Planix, Inc.

<>       +1 416 218 0099

Attachment: pgp1G8SPVJJ8O.pgp
Description: PGP signature

Home | Main Index | Thread Index | Old Index