Re: [PATCH] Replace hard-coded path with one configurable at make time

[Chris Webb <chris@arachsys.com>]

Junio C Hamano <gitster@pobox.com> writes:

>  * What's the point of making this configurable, other than "because we
>    can"?

I have a local patch against git to fix these paths, as I run it on slightly
unusual systems with a non-standard directory layout (no /usr, but
/local/bin in some cases) and I don't like to see incorrect paths compiled
into my binaries. It occurred to me that if I want to fix it one way
locally, others may well want to vary it too for different reasons, e.g. to
add /opt/bin or /usr/gnu to the default path.

Ultimately, I guess it feels like it should be configurable rather than
needing to be patched in the source for the same reason prefix or gitexecdir
is, but this is definitely for a minority audience!

Were it just exec_cmd.c, I would just have changed it to use _PATH_DEFPATH
from <paths.h> in preference to a make variable, as that should always give
an appropriate value for a correctly put-together system and is a sensible
place to treat as the central definition of 'default path'. However, in this
case it's needed in the shell script too and I don't think I can easily get
at _PATH_DEFPATH from there.

>  * Use of "$(x_SQ)" is about protecting whitespaces and single quotes in
>    the literal from make and shell, but does not have anything to do with
>    protecting things like $foo in that literal from the location $x is
>    eventually embedded in.  As long as paths on DEFPATH do not have double
>    quote in it (which would be a sane assumption), the patch to exec_cmd.c
>    would work fine, but I don't know if you need an extra quoting when
>    DEFPATH is used in shell scripts.  E.g. DEFPATH=$GIT_EXEC_PATH:/usr/bin
>    would have GIT_EXEC_PATH expanded in mongoose configuration file, but
>    will not be expanded in exec_cmd.c, leading to an inconsistent
>    behaviour.

Oh I see, yes; I didn't worry about quoting it correctly in the generated
shell script, assuming it would be reasonable... but if I'm assuming it's
reasonable there's no point in the _SQ to protect the shell invoking sed in
the first place.

I also notice that the makefile makes the assumption that ' might occur in
pathological paths and so needs quoting, but then uses sed 's|x|y|g' for
(say) @@PERL@@ which will break for other pathological paths containing | or
\1 and so on. Tidying that up fully might be entertaining!

Cheers,

Chris.