FVEST@AUDUCVAX.BITNET (03/13/88)
When evaluating a command entered at the CLI prompt, before
returning an "Unknown command xxx" message, DOS should attempt
to search the S: directory (path? :-)) and if the file is found,
and execute is present in the current path, the file should be
executed. This would allow "roll-your-own" macros without having
to type "execute xxx". Please don't suggest using a shell, that's
fine, but this is something that should be present in the OS, even
MS-DOS will do this with .BAT files :-)
Floyd Vest
Auburn University
FVEST@AUDUCVAX.bitnet {...!psuvax1!auducvax.bitnet!fvest}peter@nuchat.UUCP (Peter da Silva) (03/16/88)
In article <8803130914.AA16346@jade.berkeley.edu>, FVEST@AUDUCVAX.BITNET writes: > When evaluating a command entered at the CLI prompt, before > returning an "Unknown command xxx" message, DOS should attempt ^^^ You mean the CLI > to search the S: directory (path? :-)) and if the file is found, > and execute is present in the current path, the file should be > executed. Almost. Actually, it should execute batch files anywhere in the path or the current directory without having to type "Execute". Even better would be one of the suggestions to look for a comment on the first line that indicates the processor. -- -- a clone of Peter (have you hugged your wolf today) da Silva `-_-' -- normally ...!hoptoad!academ!uhnix1!sugar!peter U -- Disclaimer: These aren't mere opinions... these are *values*.
pete@violet.berkeley.edu (Pete Goodeve) (03/17/88)
In article <795@nuchat.UUCP> peter@nuchat.UUCP (Peter da Silva) writes: >In article <8803130914.AA16346@jade.berkeley.edu>, FVEST@AUDUCVAX.BITNET writes: >> When evaluating a command entered at the CLI prompt, before >> returning an "Unknown command xxx" message, DOS should attempt > ^^^ You mean the CLI >> to search the S: directory (path? :-)) and if the file is found, >> and execute is present in the current path, the file should be >> executed. My CLI enhancer "Sili(Con:) already does this ...(:-)) >Almost. Actually, it should execute batch files anywhere in the path >or the current directory without having to type "Execute". > ...Sili(Con:) does this too (with minor restrictions). >Even better would be one of the suggestions to look for a comment on >the first line that indicates the processor. >-- Except that Execute barfs if the script has ".KEY", and it isn't the first line. >-- a clone of Peter (have you hugged your wolf today) da Silva `-_-' -- Pete -- (no relation...)
page@swan.ulowell.edu (Bob Page) (03/17/88)
peter@nuchat.UUCP (Peter da Silva) wrote: >should execute batch files anywhere in the path >or the current directory without having to type "Execute". WShell (Bill Hawes' shell) does this if the rumored script bit is on. The rumored AmigaShell (the shell of the rumored 1.3) also does it if the rumored script bit is on. One thing about WShell (I haven't tried it with the rumored AmigaShell) is that since S: isn't usually in your path, it won't look there for script files, like Execute does, so you have to add it to your path, or keep your script files someplace in your existing path. Note that at this time, AmigaShell, script bits, and 1.3 are figments of my imagination. ..Bob -- Bob Page, U of Lowell CS Dept. page@swan.ulowell.edu ulowell!page "Why? It's the heat." -- Laurie Anderson
peter@nuchat.UUCP (Peter da Silva) (03/19/88)
In article ... pete@violet.berkeley.edu (Pete Goodeve) writes: > In article <795@nuchat.UUCP> peter@nuchat.UUCP (Peter da Silva) writes: > >Even better would be one of the suggestions to look for a comment on > >the first line that indicates the processor. > Except that Execute barfs if the script has ".KEY", and it isn't the first > line. Do I have to do all your thinging for you :->? Just make that ".KEY" the marker for batch files. Nobody says that you have to be 100% consistent. You could have a command "marker" that works like this: marker .key execute $* marker #!sh shell -c $* -- -- a clone of Peter (have you hugged your wolf today) da Silva `-_-' -- normally ...!hoptoad!academ!uhnix1!sugar!peter U -- Disclaimer: These aren't mere opinions... these are *values*.