From: Jeff King <peff@peff.net>
Date: Fri, 13 Nov 2015 23:09:33 GMT
Subject: Re: [PATCH] rebase-i-exec: Allow space in SHELL_PATH
Message-ID: <20151113230933.GA16173@sigill.intra.peff.net>
In-Reply-To: <CABA5-zmmKeeDDhSdan9sTppRVeDNuPiR8WX=P4Umdbq=ELafqw@mail.gmail.com>

On Fri, Nov 13, 2015 at 11:47:40PM +0100, Fredrik Medley wrote:

> > Hmm. Now I'm a bit puzzled. It sounds like the installed file does have
> > @SHELL_PATH@ set to /bin/sh, which is normal. And presumably the setting
> > containing space is coming from the $SHELL environment variable.
> I wrote the email on another computer. Checking the system where I reinstalled
> Git for Windows yesterday shows ${SHELL:-/bin/sh} and SHELL=/usr/bin/bash
> When running "git rebase --interactive HEAD^ --exec 'echo $SHELL'", I get
> mingw64/libexec/git-core/git-rebase--interactive: line 613:
> C:/Program: No such file or directory
> 
> Fixing the double quotes, "git rebase --interactive HEAD^ --exec 'echo
> $SHELL'" shows
> C:/Program Files/Git/usr/bin/bash

It looks like bash on your system may simply be filling in its absolute
path into the $SHELL variable. This seems like an interesting bash-ism:

  $ unset SHELL
  $ dash -c 'echo $SHELL'

  $ bash -c 'echo $SHELL'
  /bin/bash

If $SHELL is already set and exported, it will not override it, but in
your case $SHELL is probably local to each individual bash invocation.

So that at least kind-of makes sense. It's possible somebody could be
doing something clever with $SHELL, but I kind of doubt it. If they want
to do something clever, it is much easier to put it directly on the exec
line, and have the normal $SHELL run their clever thing.

-Peff