Re: [msysGit] git rev-parse broken on Git for Windows

From: Thomas Rast <trast@student.ethz.ch>
Date: Jul 30, 2010, 14:43 UTC
Message-ID: <201007301643.50730.trast@student.ethz.ch>
In-Reply-To: <4C52E125.1020004@workspacewhiz.com>

Joshua Jensen wrote:

Show 20 quoted lines

> Thomas Rast wrote:
> > Johannes Schindelin wrote:
> >>> eval $(echo "$OPTS_SPEC" | git rev-parse --parseopt -- "$@" || echo exit $?)
> > Can you elaborate on "break"?
> >
> > Because as you can see in git-sh-setup.sh, the "official" user of
> > parseopt does
> >
> > 	eval "$(
> > 		echo "$OPTIONS_SPEC" |
> > 			git rev-parse --parseopt $parseopt_extra -- "$@" ||
> > 		echo exit $?
> > 	)"
> >
> > So AFAICS they only differ in the quoting.  And the latter works.
> Here is the output from Git Bash:
> 
> $ git subtree
> C:\Program Files (x86)\Git/libexec/git-core/git-subtree: eval: line 31: 
> syntax error near unexpected token `<'

[...]

> The example from the git rev-parse documentation fails in the same way:
> 
> eval `echo "$OPTS_SPEC" | git rev-parse --parseopt $parseopt_extra -- 
> "$@" || echo exit $?`

Oh, sorry that I was so dense in the first reply. Of course the quoting is the problem. When unquoted, the shell first splits along whitespace and then eval reassembles with *one space* between each pair of words. The change just exacerbated the issue; there are other ways to trigger bad behaviour if the eval uses an unquoted --parseopt:

  # what you saw
  $ echo eval $( (echo 'description'; echo --; echo "s,long= foo") | git rev-parse --parseopt -- --help || echo exit $?)
  eval cat <<\EOF usage: description -s, --long ... foo EOF exit 129

  # newlines are clobbered
  $ echo eval $( (echo 'description'; echo --; echo "s,long= foo") | git rev-parse --parseopt -- --long="$(printf 'argument\nwith\nnewlines')" || echo exit $?)
  eval set -- -s 'argument with newlines' --

  # consecutive spaces are also clobbered
  echo eval $( (echo 'description'; echo --; echo "s,long= foo") | git rev-parse --parseopt -- --long="three   spaces" || echo exit $?)
  eval set -- -s 'three spaces' --

So I'm afraid Avery will have to fix this in git-subtree. I'll also follow up with a doc patch for git-rev-parse. Luckily there are no users in git outside of tests and git-sh-setup, so there are no bugs.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch