physh@unicom.UUCP (Jon 'Quality in - Quantity out' Foreman) (12/10/87)
As everyone knows, unix figures out how to run something by
examining it magic number (or for shell scripts, its lack thereof.) I
have often found a need for overriding a shells behavior of treating
* and ? etc, as special in someway. For instance, I always wanted
programs like "send" and "reply" from TOPS 20, so under UNIX I could
say: "send bar I'll meet you for lunch?" and bar could "reply sure!"
and not have it choke on the quote, question mark or exclaimation point.
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 kernel could
recognize this header and just skip over it if it doesn't need anything
from it.
Even just a mechanism in the shell to do this on named programs
would be nice (sorta like alias, say, unglob send; unglob reply.)
--
{ucbvax,hoptoad}!\ ~~~~~~~\~~~ That's spelled
{lll-lcc,hplabs}!well!unicom!physh Jon }() "physh" and
{ptsfa,dual}!/ / pronounced "fish".hydrovax@nmtsun.nmt.edu (M. Warner Losh) (12/14/87)
In article <216@unicom.UUCP>, physh@unicom.UUCP (Jon 'Quality in - Quantity out' Foreman) writes: > > 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? In a way VMS already supports this. It doesn't place a header on the file, it keeps its own tables of what to do with each command. It is really quite easy to use and promotes more of a standard fel to the operating system. After all, without aliasing, what system allows you to abbreviate commands to their shortest, unique part. That means that you can type DIRECTORY or DIR (or any number of letters in between). or (to take an example from the receince past of the net): $ DELete *.OBJ/COnfirm Here case is used to tell you what you the minimal needed to enter the command. Case doesn't matter in VMS :-) The DELETE program needs only to make one call to VMS to find out if the /COONFIRM qualifier is present. BTW, is there a magic cookie for RM that tells you what files it is deleting? I didn't see one in the man page. I have a SLOW shell script to do this (when I need to do this). One last note, this is for informational purposes only. I don't want to start the religious war up again (VMS vs UNIX vs *). Just thought that this might make the discussion more complete. Warner ...!lanl!unm-la!unmvax!nmtsun!warner%hydrovax -- bitnet: lush@nmt.csnet M. Warner Losh csnet: warner%hydrovax@nmtsun uucp: ...{cmcl2, ihnp4}!lanl!unmvax!nmtsun!warner%hydrovax ...{cmcl2, ihnp4}!lanl!unmvax!nmtsun!hydrovax Warning: Hydrovax is both a machine, and an account, so be careful.
martin@kuling.UUCP (Erik Martin) (12/15/87)
In article <216@unicom.UUCP> physh@unicom.UUCP writes: > >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 kernel could >recognize this header and just skip over it if it doesn't need anything >from it. I would prefer a separate module for the shell, written in the shell command language (which should be *compilable*!). Loading such a module into the shell "defines" a program as a command. Without a parser module the shell should never touch the command line input, but just pass it to the program. It is definitely possible to write a shell for Unix after this sketch, but it has some weakness. One is that the arguments will be parsed twice: once bye the shell so you can get completion, and help (as in TOPS-20) and so on, and once by the program. When designing a new operating system, I would perhaps use different methods for passing arguments from the user and to a program (through the shell's parser module) and between two programs, and thus always requiring a parser module for each program (which may be auto-loaded in some way). -- ((Per-Erik Martin, Computing Science Dept., Uppsala University, ) (Box 520, S-751 20 Uppsala, Sweden ) (UUCP: martin@kuling.UUCP (...!{seismo,mcvax}!enea!kuling!martin)))