🚀 go-pugleaf

In article <ggk.659154896@tirith.UUCP> ggk@tirith.UUCP (Gregory Kritsch) writes:
>Glad to hear "they're in there" finally at least.  I hope that they'll
>do Unix style flag parsing if asked (although I doubt it somehow). 

	Nope.  Standard ReadArgs (ala the c: commands) parsing, with a number
of extensions (/N for numbers, /M for multiple strings, etc).

>I really think that having the application program not handle any
>quoting or expansion would be a real plus.  That way, I can have the
>shell do expansion via my wildcards (Hey, I like the "mumble" wildcard
>better than '*' or '#?', ie: mumble.info representing all the files
>ending in .info), and I can depend on being able to pass all 256 ascii
>characters in command arguments, without worrying about the program not
>doing quoting.

	Standard quoting is handled by the ReadArgs function.  If this isn't
what the program wants, it can do whatever it wants with the command line
instead of, before, or after calling ReadArgs.  Personally, I feel that
expansion should be handled by the command for several reasons.  I prefer that
if a shell is doing expansion, it should do it when the user requests it (hits
some key, by command, whatever).  I once wrote a shell where you could
specify which commands would have the arguments expanded (or not expanded).
I ended up never using this, and instead I use user-initiated expansion.
This is, of course, a partially religious issue.

-- 
Randell Jesup, Keeper of AmigaDos, Commodore Engineering.
{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com  BIX: rjesup  
Thus spake the Master Ninjei: "If your application does not run correctly,
do not blame the operating system."  (From "The Zen of Programming")  ;-)