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

[Thomas Rast <trast@student.ethz.ch>]

Joshua Jensen wrote:
> 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