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. > > Also, eval treats data as code, and if for some reason this should end up in a > setuid environment (perhaps as a web application), eval would generate a > trivially accessed gigantic security hole. Huh? It could execute arbitrary code, like an editor. Which is the whole point of the variable. What you might be thinking of is that it might execute material which has a non-local impact on the calling environment. If that is your concern, just wrap the eval inside of parens, like (eval ...). But frankly: setuid shell scripts are a security hole fit to drive a truck through, anyway. One does not need eval for that. -- 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
