Re: [PATCH] allow git to use the PATH for finding subcommands and help docs
- From
Johannes Sixt <j.sixt@viscovery.net>
- Date
- Oct 19, 2007, 14:34 UTC
- Message-ID
- <4718C072.2070505@viscovery.net>
- In-Reply-To
- <20071019141805.GE1463@srparish.net>
Scott Parish schrieb:
Show 26 quoted lines
> On Fri, Oct 19, 2007 at 03:21:12PM +0200, Johannes Sixt wrote: > >> Scott Parish schrieb: >>> I have a situation where software for a distribution is installed >>> into a fake "prefix" and then moved to one of several potential >>> places to be used by users. Given that the final location isn't >>> static, i can't depend on builtin_exec_path. I'd really like users >>> to be able to get started with git as easily as possible. With the >>> current setup, they would have to create and maintain either an >>> GIT_EXEC_PATH or an alias for including --exec-path, as well as a >>> MANPATH and PERL5LIB. This seem like an unnessisary burden. >> Interesting. How does this compare to this 2-patch-series: >> >> http://repo.or.cz/w/git/mingw.git?a=commitdiff;h=e479ea2f911b8c70a269ba59372a4fef90f8907c >> http://repo.or.cz/w/git/mingw.git?a=commitdiff;h=00a4ff4f3f8ec7e6b3ac15456f00b22b03f438ae >> >> which I had come up with to accomplish something very similar >> (on Windows). Your approach looks superior, but I hadn't gone >> into depths, yet. > > I know very little about what's available on windows. Looking at > your code, it looks like the command isn't passed in in argv[0] and > that it contains the windows style path seperators. My code currently > assumes that PATH is a colon separated list, and that directories > are separated with '/'. How should these assumptions change for > windows?
The question is rather whether my patches would be sufficient to also achieve your requirements. They turn bultin_exec_path into a non-constant that derives exec-path from argv[0] (which on Windows happens to be available in the global _pgmptr). Isn't this enough, or at least the essence of what you need?
(How to get to the value of _pgmptr, ie. argv[0], on non-Windows is a secondary matter.)
-- Hannes