Re: Execute a string as a command

[Emanuel Berg]

Tim Johnson <tim@akwebsoft.com> writes:

> By this time, you've probably read from the
> continuation of this thread that I had problems with
> setting up the menu structure so that command
> objects could be read from it. Thus I used a string
> representation to see if that could be evaluated.

I don't use menus so I can't say but my gut feeling
tells me that to keep commands as strings to be
evaluated isn't a good idea.

It is disencouraged in shell scripting as well (e.g.,
bash, zsh). And isn't the famous SQL injection attack
based on somewhat the same data/code intermingling?

One problem is the string needs to be parsed somehow
into code. You may say this happens all the time when
programming. However when programming, even tho you
aren't compiling your code, after each evaluation of
a function, that function is simply invoked. At that
stage the function is at least formally correct in the
sense that evaluation was possible. But, in your menu
case, evaluation must be done each time. Otherwise it
is just a string. This is not only inefficient, it is
also insecure as there is no telling if that string
holds anything that can sensibly be put together into
a function.

The argument problem has been mentioned. In general,
commands that are not strings but commands hold much
more power. Much more stuff can be done with them, and
around them: e.g., advices, lambdas, keybindings, and
probably a lot more.

> I have since found the right combination of menu
> syntax and 'eval syntax to make the command
> objects readable.

In old Lisp books (e.g., [1]), `eval' is one of the
first things they mention and they put it as
a cornerpiece of Lisp. Since then this has changed and
eval should only be used with what is explicitly
commands, i.e. stuff that is beyond doubt prepared
for execution. In your case, you have used it correct.
Another example might be:

    (eval (car command-history) )

Here, both the name and the docstring "List of recent
commands..." support the use of `eval'. (Other people
can tell you more about why you shouldn't use
eval otherwise.)

> Thanks ... for your replies. They are
> always enlightening.

Well, "always" may be stretching it just a bit :)

% [1]
@book{artificial-intelligence-and-the-design,
  title      = {Artificial Intelligence and the Design of Expert Systems},
  author     = {George Luger; William Stubblefield},
  publisher  = {Benjamin-Cummings},
  year       = 1989,
  ISBN       = 0805301399
}

--
underground experts united
http://user.it.uu.se/~embe8573