andrew@frip.gwd.tek.com (Andrew Klossner) (12/12/87)
[]
"Since the binary images have so much extra information in them
already (symbol table, reloadability when pure, etc), why not
add yet another optional header, say 1024 bytes long, which
defines how arguments are supposed to be handled? Then a
command interpreter such as sh(1) or csh(1) or tcsh(1?) etc.
can just open the file, read 1024 and have some method of
resolving such sillyness."
The shell doesn't normally read a file before executing it; it only
tries to open the file if the exec(2) call fails (meaning it's not a
binary executable, so maybe it's a shell script).
Besides the performance impact (making the shell read every command
file) and the massive hair imposed by changing the a.out structure
(which dozens of utilities "know"), this technique would fail because
of execute-only files, which the shell can't examine.
I haven't yet seen the TENEX approach mentioned: as soon as you hit the
space after the command name, the program runs and it reads the rest of
the command line. Under some circumstances the program may even supply
in-line prompts, a facility made easy by the fact that the tty driver
doesn't echo a character until the application reads it. An
example would be:
rm [file-name] *.o [are you sure?]
^ ^ ^ ^
^ ^ ^ User hit carriage return; system doesn't echo
^ ^ ^ it, but asks for confirmation instead.
^ ^ User enters *.o
^ As soon as user types a space, the command runs and prompts
^ for the argument.
All the shell reads is "rm ".
This isn't a real example; it's been fourteen years since I typed a
TENEX command and I don't remember any specific ones. I believe the
in-line prompting was provided only to novices, and that experts could
disable it. Needless to say, this made it very easy for a novice to
operate. (You could also enter a ? at any point in this dialog to get
help.)
-=- Andrew Klossner (decvax!tektronix!tekecs!andrew) [UUCP]
(andrew%tekecs.tek.com@relay.cs.net) [ARPA]