threads / discuss / 18341

--exec-path not always honored

Subject: --exec-path not always honored

## tl;dr

5 messages between Mar 17, 2009 and Mar 18, 2009.

replies: 4people: 3as markdown or json

Johannes Sixt· Mar 17, 2009, 09:11 UTC · lore

I noticed this failure if I run git from the build directory:

$ ./git --exec-path=. gc
usage: git pack-objects [{ -q | --progress | --all-progress }]
        [--max-pack-size=N] [--local] [--incremental]
        [--window=N] [--window-memory=N] [--depth=N]
        [--no-reuse-delta] [--no-reuse-object] [--delta-base-offset]
        [--threads=N] [--non-empty] [--revs [--unpacked | --all]*] [--reflog]
        [--include-tag] [--keep-unreachable | --unpack-unreachable]
        --stdout | base-name < ref-or-object-list
error: failed to run repack

The reason is that the version of pack-objects that I have installed in $prefix does not know the option --kept-pack-only, which ./git-repack passes along. It doesn't matter whether I have $prefix in PATH or not.

But on the other hand:

$ ./git --exec-path=. repack -a -d Counting objects: 104070, done. Delta compression using 2 threads. Compressing objects: 100% (26161/26161), done. Writing objects: 100% (104070/104070), done. Total 104070 (delta 76376), reused 104070 (delta 76376)

works just fine whereas without --exec-path it fails like git-gc above.

git-gc is a builtin. Should git setenv("GIT_EXEC_PATH") before it runs other git commands?

-- Hannes

Johannes Schindelin· Mar 17, 2009, 10:19 UTC · re: Johannes Sixt · lore

Re: --exec-path not always honored

Hi,

On Tue, 17 Mar 2009, Johannes Sixt wrote:

> I noticed this failure if I run git from the build directory:
> 
> $ ./git --exec-path=. gc

I am not sure if "." is what you think it is; I imagine it would be $GIT_DIR by the time the PATH variable is adjusted.

Could you try again with

	$ ./git --exec-path="$(pwd)" gc

Thanks, Dscho

Johannes Sixt· Mar 17, 2009, 10:34 UTC · re: Johannes Schindelin · lore

Re: --exec-path not always honored

Johannes Schindelin schrieb:

Show 8 quoted lines

> On Tue, 17 Mar 2009, Johannes Sixt wrote:
> 
>> I noticed this failure if I run git from the build directory:
>>
>> $ ./git --exec-path=. gc
> 
> I am not sure if "." is what you think it is; I imagine it would be 
> $GIT_DIR by the time the PATH variable is adjusted.

This would be *very* bogus, wouldn't it?

Show 5 quoted lines

> Could you try again with
> 
> 	$ ./git --exec-path="$(pwd)" gc
> 
> ?

It fails in the same way:

$ ./git --exec-path=$(pwd) gc usage: git pack-objects blah blah... error: failed to run repack

-- Hannes

Junio C Hamano· Mar 18, 2009, 05:41 UTC · re: Johannes Sixt · lore

Re: --exec-path not always honored

Johannes Sixt <j.sixt@viscovery.net> writes:

> git-gc is a builtin. Should git setenv("GIT_EXEC_PATH") before it runs
> other git commands?

I think we just never have bothered about such a use case, but you are right. It probably is a good solution, although setenv makes me feel a bit nervous for no rational reason.

Johannes Sixt· Mar 18, 2009, 07:42 UTC · re: Junio C Hamano · lore

Re: --exec-path not always honored

Junio C Hamano schrieb:

Show 8 quoted lines

> Johannes Sixt <j.sixt@viscovery.net> writes:
> 
>> git-gc is a builtin. Should git setenv("GIT_EXEC_PATH") before it runs
>> other git commands?
> 
> I think we just never have bothered about such a use case, but you are
> right.  It probably is a good solution, although setenv makes me feel a
> bit nervous for no rational reason.

This patch fixes the use case and is IMO the most logical solution.

diff --git a/exec_cmd.c b/exec_cmd.c
index 217c125..408e4e5 100644
--- a/exec_cmd.c
+++ b/exec_cmd.c
@@ -61,6 +61,10 @@ const char *git_extract_argv0_path(const char *argv0)
 void git_set_argv_exec_path(const char *exec_path)
 {
 	argv_exec_path = exec_path;
+	/*
+	 * Propagate this setting to external programs.
+	 */
+	setenv(EXEC_PATH_ENVIRONMENT, exec_path, 1);
 }