Re: [PATCH] Fix relative built-in paths to be relative to the command invocation

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

 



Zitat von Johannes Schindelin <Johannes.Schindelin@xxxxxx>:

> Hi,
>
> On Sun, 13 Jul 2008, Johannes Sixt wrote:
>
> > diff --git a/Makefile b/Makefile
> > index 4796565..2bdb9bf 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -1301,7 +1301,7 @@ remove-dashes:
> >  ### Installation rules
> >
> >  ifeq ($(firstword $(subst /, ,$(template_dir))),..)
> > -template_instdir = $(gitexecdir)/$(template_dir)
> > +template_instdir = $(shell cd '$(bindir_SQ)/$(template_dir_SQ)' && pwd)
>
> What is this for?  Did the original line stop working?

I could just have changed $(gitexecdir) to $(bindir), but in the
make-execpath-relative patch we will need the normalized gitexec_instdir
because its value is compared to $(bindir). So the extra $(shell...) in
_this_ patch is only that the final result looks consistent.

> > diff --git a/exec_cmd.c b/exec_cmd.c
> > index 8899e31..45f92eb 100644
> > --- a/exec_cmd.c
> > +++ b/exec_cmd.c
> > @@ -5,6 +5,7 @@
> >
> >  extern char **environ;
> >  static const char *argv_exec_path;
> > +static const char *argv0_path;
> >
> >  static const char *builtin_exec_path(void)
> >  {
> > @@ -42,14 +43,19 @@ static const char *builtin_exec_path(void)
> >
> >  const char *system_path(const char *path)
> >  {
> > -	if (!is_absolute_path(path)) {
> > +	if (!is_absolute_path(path) && argv0_path) {
> >  		struct strbuf d = STRBUF_INIT;
> > -		strbuf_addf(&d, "%s/%s", git_exec_path(), path);
> > +		strbuf_addf(&d, "%s/%s", argv0_path, path);
> >  		path = strbuf_detach(&d, NULL);
> >  	}
> >  	return path;
> >  }
> >
> > +void git_set_argv0_path(const char *path)
> > +{
> > +	argv0_path = path;
> > +}
> > +
> >  void git_set_argv_exec_path(const char *exec_path)
> >  {
> >  	argv_exec_path = exec_path;
> > @@ -84,7 +90,7 @@ static void add_path(struct strbuf *out, const char
> *path)
> >  	}
> >  }
> >
> > -void setup_path(const char *cmd_path)
> > +void setup_path(void)
>
> It seems to me that this patch would not do anything different, but with
> less code change, if setup_path() would set argv0_path, and not a new
> function was introduced.

This is just to play a safe game. I had it that way, but I decided to have
the call to the new git_set_argv0_path() early in git.c because the call
to setup_path() in git.c is very late, and it could happen that we call
system_path() (which needs argv0_path) before that. Although I didn't audit
the code whether this really happens.

-- Hannes


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux