Uninterpreted command line

[utzoo!decvax!ucbvax!unix-wizards]

>From csk at UCLA-Security Sun Nov 15 22:01:06 1981
Several years ago, LISP systems discovered that some functions
wanted to receive their arguments unevaluated (LISP normally
evaluates arguments, and pairs them with the formal arguments
of the called procedures).  Thus, they invented syntax to specify
whether a function should have its arguments evaluated, and/or
whether the function should have a fixed or variable number
of arguments.

We could add a mode to files so that if the file is executed
(either as a shell program or as a load module), then it will
receive its arguments unevaluated (i.e. wild card and other
regular expression and shell parsing not performed) and have
the shell test this in deciding whether to parse arguments.

Unfortunately, what do we do about pipes, I/O redirection, and
(in the CSH) history substitution?  That is, suppose you
want to redirect output for one of those commands marked
not to evaulate arguments?
i.e. foo >bar     is ">bar" passed as an argument or processed
by the shell?
One could argue that if a program really wants to see its
arguments, then it should do its own redirection, pipes, etc.
However, it does NOT have the context of the parent shell
to perform that properly (shell variables, history list, etc)!
Thus, it will be difficult to build a command that really does
that in a reasonable way.

What all this says is, is it really worth it to add that feature?

--charley