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