Junio C Hamano <gitster@xxxxxxxxx> writes:
> merlyn@xxxxxxxxxxxxxx (Randal L. Schwartz) writes:
>
>>>>>>> "Bill" == Bill Lear <rael@xxxxxxxxxx> writes:
>>
>> Bill> I was told eval was "wrong on multiple levels".
>>
>> I should elaborate.
>>
>> Using "eval" here means that you *then* have to be careful
>> about whitespace quoting. For example, if my $HOME had a
>> space in it, EDITOR="$HOME/bin/superemacs" would be broken if
>> you add the extra eval, since the whitespace would be treated
>> as a delimeter on the second lexing. I'd have to figure out
>> how to set EDITOR with the right quotes or backwhacks in it to
>> undo the effect of your eval.
>
> All true.
You can't have both the ability to use a command with options as well
as an unquoted command with spaces in its path. It is rather
glaringly obvious. A space is a space is a space. Without a way of
quoting it, the argument splitting space is the same the
path-contained one.
If you do something like
woozle='"a b c"'
set $woozle
echo $1
echo $2
echo $3
you get
"a
b
c"
Quotes don't get reinterpreted. At this level, only IFS-splitting
occurs. You need eval for another level of quote interpretation.
> Does the one in git-sh-setup.sh do that correctly? For
> arguments I think it does the right thing (eval ... '"$@"' means
> "give the four letter string " $ @ " to the shell, have it
> expand and split the args --- which essentially means do not
> molest them with $IFS). For the command name part, it does:
>
> eval "${GIT_EDITOR:=vi}" '"$@"'
>
> which means that you need to say
>
> GIT_EDITOR="'/home/my programs/emacs' -nw"
>
> if you installed your emacs in "/home/my programs/" directory
> and want to pass a single leading parameter "-nw" to it.
For example.
> Is that how other programs mentioned in the thread handle $EDITOR?
If you are lucky. There is also the possibility that they just split
on spaces without a way of quoting (see above), and in that case path
names with spaces in them become completely impossible.
I am not going to test all those applications _again_: the current
code allows specifying commands with spaces in their names (by
quoting) as well as commands with arguments, and both in an obvious
manner. This is strictly better than being only able to do one or the
other.
I don't think you should revert the patch based on quite unspecific
whining of someone who chose not to read the original discussion, but
of course it is your call to make.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
-
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
