PAAAAAR%CALSTATE.BITNET@cunyvm.cuny.edu (03/07/88)
I want to ventilate a peeve that I have developed over two or three years
of Unix usage, admin and hackery. It is about "shell escapes".
They are a neat idea and easy to implement (gurus do it in a shell script:-).
But think about this 'Mail' response:
Unknown command: "cat"
How come they don't know about 'cat'?
My problem is that there *is* a more helpful way to get shell commands than
(1) learning to type '!' in front of commands that didn't need it before
and
(2) learning to NOT type '!' before other commmands.
How else could it work, you ask?
Try this
If the input fails to parse as a command in the current program,
the program tests to see if it is a valid shell command and if and only
if it is the program spawns a shell to obey it.
Thus
there should be a library function that tests whether the first
lexeme in a string is a valid shell command in the user's current shell.
Copywrite: Richard J Botting, Cal State U, San Berd'o, 1988.
The above ideas can be used and quoted free of charge by anyone
as long as this notice is included with the quotation.
Disclaimer - neither I or CSUSB is responsible for any costs incurred by
implementing these ideas.
Dick Botting
PAAAAAR@CCS.CSUSCC.CALSTATE(doc-dick)
paaaaar@calstate.bitnet
PAAAAAR%CALSTATE.BITNET@{depends on the phase of the moon}
Dept Comp Sci., CSUSB, 5500 State Univ Pkway, San Bernardino CA 92407
voice:714-887-7368 modem:714-887-7365 -- Silicon Mountain
"where smog of LA, is blown away, and the sun shines bright all the day"!dce@mips.COM (David Elliott) (03/07/88)
In article <12162@brl-adm.ARPA> PAAAAAR%CALSTATE.BITNET@cunyvm.cuny.edu writes: >I want to ventilate a peeve that I have developed over two or three years >of Unix usage, admin and hackery. It is about "shell escapes". ... >How else could it work, you ask? >Try this > If the input fails to parse as a command in the current program, > the program tests to see if it is a valid shell command and if and only > if it is the program spawns a shell to obey it. While the sentiment is sound, there are some difficulties that come to mind: 1. How do you handle extensions to the parsed language? 2. There are incompatabilities between parsed languages. How do you explain to a naive user that typing 'x' in one command exits the command, while 'x' in another executes a shell command called 'x'. 3. The only reasonable way to test if something is a shell command is to go ahead and try (otherwise, you have to put the intelligence of the shell into the program). If you say "only shell builtins", you have to assume a shell (many people have written their own shells), and most shell builtins are not useful alone. 4. How do you handle spelling errors? "I typed the word edit instead of exit and it threw me into the editor." There are worse cases that can be conceived. 5. Many interactive commands use special terminal modes that make it impossible to use a shell lexeme analyzer. At least with !, you know what you are getting yourself into. In any event, what you want is a form of job control. Instead of cluttering up each program with a shell escape mechanism, you provide a way to escape from the current command to execute new commands. There are many ways to do this: Berkeley job control, shell layers, windows; all currently implemented and shown to be quite useful. > Copywrite: Richard J Botting, Cal State U, San Berd'o, 1988. > The above ideas can be used and quoted free of charge by anyone > as long as this notice is included with the quotation. It's spelled "copyright". I wonder, does the fact that the spelling is incorrect affect the validity of the copyright? The validity of the request? -- David Elliott dce@mips.com or {ames,prls,pyramid,decwrl}!mips!dce
chris@mimsy.UUCP (Chris Torek) (03/08/88)
In article <12162@brl-adm.ARPA> PAAAAAR%CALSTATE.BITNET@cunyvm.cuny.edu writes: >If the input fails to parse as a command in the current program, >the program tests to see if it is a valid shell command and if and only >if it is the program spawns a shell to obey it. What with the vagaries of paths, shell `rc' files, aliases, and such, the only reliable way to discover whether something is a `valid shell command' is by issuing it. >Copywrite: Since you misspelled it, I deleted the rest :-) . -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
davidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr) (03/08/88)
I don't think this is a good idea. Perhaps in a world where no one
mistyped a command of got a command zapped by communications lines, but
not for me, thanks.
UNIX does enough interesting things with mistyped commands at the
shell level, without adding a "pseudo shell" level.
Implementation: I guess you could chase the path yourself, but that
would be a pain. The Korn shell "whence" command will return a path for
any valid command including builtins. You could popen the shell and ask
if the command is valid.
Yes, I know I'm telling him how to implement a bad idea, but I hate
people who won't let me make a fool of myself...
--
bill davidsen (wedu@ge-crd.arpa)
{uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me