Path: utzoo!utgpu!water!watmath!clyde!rutgers!ucla-cs!zen!ucbvax!decvax!decwrl!sun!pitstop!sundc!seismo!uunet!mcvax!enea!kuling!martin From: martin@kuling.UUCP (Erik Martin) Newsgroups: comp.unix.wizards Subject: Re: Command interface interim suggestion Keywords: command interface, globbing, tomfoolery, kudgery Message-ID: <579@kuling.UUCP> Date: 14 Dec 87 16:15:19 GMT References: <216@unicom.UUCP> Reply-To: martin@kuling.UUCP (Per-Erik Martin) Organization: Dept. of Computer Systems, Uppsala University, Sweden Lines: 28 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)))