patchFallback on _NSGetExecutablePath to get the executable path if using argv[0] fails

>
> Signed-off-by: Jeremy Huddleston <jeremyhu@apple.com>
> Reviewed-by: Matt Wright <mww@apple.com>
> ---
>  exec_cmd.c |   17 +++++++++++++++++
>  1 files changed, 17 insertions(+), 0 deletions(-)
>
> diff --git a/exec_cmd.c b/exec_cmd.c
> index bf22570..1e24a8f 100644
> --- a/exec_cmd.c
> +++ b/exec_cmd.c
> @@ -3,6 +3,10 @@
>  #include "quote.h"
>  #define MAX_ARGS       32
>
> +#if defined(__APPLE__) && defined(RUNTIME_PREFIX)
> +#include <mach-o/dyld.h>
> +#endif
> +
>  extern char **environ;
>  static const char *argv_exec_path;
>  static const char *argv0_path;
> @@ -53,6 +57,19 @@ const char *git_extract_argv0_path(const char *argv0)
>        if (slash >= argv0) {
>                argv0_path = xstrndup(argv0, slash - argv0);
>                return slash + 1;
> +#ifdef __APPLE__

> This adds better support for RUNTIME_PREFIX on Mac OS X.  The previous codepath
> would only work if argv[0] contained the full path to the executable or $PATH
> already contained /path/to/libexec/git-core.  We use _NSGetExecutablePath here
> to find the full path (and thus prepend the correct libexec/git-core to $PATH)
> in the case where argv[0] does not contain the full path to the executable.

> @@ -53,6 +57,19 @@ const char *git_extract_argv0_path(const char *argv0)
>  	if (slash >= argv0) {
>  		argv0_path = xstrndup(argv0, slash - argv0);
>  		return slash + 1;
> +#if defined(__APPLE__)
> +	} else {
> +		char new_argv0[PATH_MAX];
> +		uint32_t new_argv0_s = PATH_MAX;
> +		if(_NSGetExecutablePath(new_argv0, &new_argv0_s) == 0) {
> +			slash = new_argv0 + strlen(new_argv0);
> +			while (new_argv0 <= slash && !is_dir_sep(*slash))
> +		                slash--;
> +
> +			if (slash >= new_argv0)
> +				argv0_path = xstrndup(new_argv0, slash - new_argv0);
> +		}
> +#endif

>> --- a/exec_cmd.c
>> +++ b/exec_cmd.c
> [...]
>> @@ -53,6 +57,19 @@ const char *git_extract_argv0_path(const char *argv0)
>>  	if (slash >= argv0) {
>>  		argv0_path = xstrndup(argv0, slash - argv0);
>>  		return slash + 1;
>> +#if defined(__APPLE__)
>> +	} else {
>> +		char new_argv0[PATH_MAX];
>> +		uint32_t new_argv0_s = PATH_MAX;
>> +		if(_NSGetExecutablePath(new_argv0, &new_argv0_s) == 0) {
>> +			slash = new_argv0 + strlen(new_argv0);
>> +			while (new_argv0 <= slash && !is_dir_sep(*slash))
>> +		                slash--;
>> +
>> +			if (slash >= new_argv0)
>> +				argv0_path = xstrndup(new_argv0, slash - new_argv0);
>> +		}
>> +#endif
>
> Can't this ifdef be avoided?  The ideal is for such code to be
> abstracted away into helper functions in git-compat-util.h and compat/*.c.

> Jonathan Nieder <jrnieder@gmail.com> writes:
> 
>>> --- a/exec_cmd.c
>>> +++ b/exec_cmd.c
>> [...]
>>> @@ -53,6 +57,19 @@ const char *git_extract_argv0_path(const char *argv0)
>>> 	if (slash >= argv0) {
>>> 		argv0_path = xstrndup(argv0, slash - argv0);
>>> 		return slash + 1;
>>> +#if defined(__APPLE__)
>>> +	} else {
>>> +		char new_argv0[PATH_MAX];
>>> +		uint32_t new_argv0_s = PATH_MAX;
>>> +		if(_NSGetExecutablePath(new_argv0, &new_argv0_s) == 0) {
>>> +			slash = new_argv0 + strlen(new_argv0);
>>> +			while (new_argv0 <= slash && !is_dir_sep(*slash))
>>> +		                slash--;
>>> +
>>> +			if (slash >= new_argv0)
>>> +				argv0_path = xstrndup(new_argv0, slash - new_argv0);
>>> +		}
>>> +#endif
>> 
>> Can't this ifdef be avoided?  The ideal is for such code to be
>> abstracted away into helper functions in git-compat-util.h and compat/*.c.
> 
> I had exactly the same reaction.  Also doesn't the above need to be
> protected by defined(RUNTIME_PREFIX), too?

> Thiago Farina wrote:
>> On Mon, Nov 29, 2010 at 2:57 PM, Jeremy Huddleston <jeremyhu@apple.com> wrote:
> 
>>> Signed-off-by: Jeremy Huddleston <jeremyhu@apple.com>
>>> Reviewed-by: Matt Wright <mww@apple.com>
> 
> I like the idea, but could you add a short commit message
> explaining the existing behavior and what improvement this makes?

> Jeremy Huddleston wrote:
>> On Nov 29, 2010, at 12:12, Jonathan Nieder wrote:
> 
>>> The section "2) #ifdefs are ugly" of
>>> linux-2.6/Documentation/SubmittingPatches explains the rationale.
>> 
>> I agree, but I don't really see a way around it here since this API is specific to OS X.
> 
> Did you actually read that section? :)

>>>> The section "2) #ifdefs are ugly" of
>>>> linux-2.6/Documentation/SubmittingPatches explains the rationale.
>>> 
>>> I agree, but I don't really see a way around it here since this API is specific to OS X.
>> 
>> Did you actually read that section? :)
>
> Yes, but I don't have the time to "do it right" right now ... I'm
> contributing the patch that we are using back to the community in
> the spirit of OSS development, but I don't have the time resources
> currently to "do it right" at present.  I'll come back to it once
> time allows if nobody else picks it up.

> Kevin Ballard wrote:
>> On Nov 29, 2010, at 9:12 AM, Jonathan Nieder wrote:
> 
>>> The section "2) #ifdefs are ugly" of
>>> linux-2.6/Documentation/SubmittingPatches explains the rationale.
>> 
>> Might this be worth pulling into git.git/Documentation/CodingGuidelines?
> 
> Yes, the example there includes good advice I wish I had received
> sooner, and Documentation/CodingGuidelines seems like a good place to
> help people find it.  Do you have some wording in mind?