1. A new method of passing command line arguments to A-Shell is now available, which may be useful in situations like CGI where you don't have as much control as you might like over the arguments that are being specified on the A-Shell command line. It works like this:
If A-Shell is invoked with no arguments, or if the first argument does not start with a "-", or if the A-Shell executable is not the standard one (ashw32.exe or ashell), THEN it looks for a file in the same directory and with the same name as the ashell executable but with an extension of ".cl" (e.g. ashell.cl or ashw32.cl). If found it is expected to contain a single line of command arguments to A-Shell. The first line is thus parsed into tokens, and the tokens are inserted into the command line prior to any arguments which were on the original command line. This allows you, for example, to specify the "-i " parameter even when it is not possible to have it supplied explicitly on the A-Shell command line. An example may make this more clear.
Let's take the case of CGI, in which the you can specify an arbitrary executable path for the CGI program in the web form, but you may not be able to specify any arguments. Previously, the only way to use A-Shell as a CGI engine in this case would be to create a front-end script that in turn contained the full A-Shell command line. Now what you can do is put a copy (or just a link) of the A-Shell executable in new directory, say, /vm/web. Give its path as the CGI executable spec in the web form (i.e. /vm/web/ashell). Then create a /vm/web/ashell.cl file that contains the rest of the command line, e.g.:
-i /vm/web/miame.ini -cgi cgigo 2>/tmp/cgi.err
When /vm/web/ashell starts up, since it was not passed any arguments, it will see the /vm/web/ashell.cl file and insert the contents (line 1 only) into its own argument list.
Another example situation would be where you have some kind of existing module that is capable of invoking arbitrary external commands of the form:
The makers of this program perhaps expected you to use this facility to launch your own file editor, or print utility. But you want to use A-Shell to operate on the using your own custom logic. Previously, it would have been awkward to work with this command line, due to the need to predefine the MIAME environment variable, not to mention the problem of using a native filespec argument where A-Shell would have been expecting an AMOS command file name. Now, by setting up a cl file in the same directory as the ashell executable, you can invoke your own program on the , perhaps something like this:
-i c:\vm\miame\miame.ini myprog
The assumption here is that 'myprog' is actually a DO file which will then receive the as its parameter, allowing you to then pass it on to a Basic program, using one of these basic techniques:
;myprog.do
:R
log myppn: ; you must log somewhere
run myapp $0 ; myapp will use LSTLIN.SBR to get $0
or
run myapp
$0 ; myapp will use INPUT to get $0
Note that in the above example, the complete ashell command line after processing the ashw32.cl file would be:
\ashw32.exe -i c:\vm\miame\miame.ini myprog
The important thing to see there is that the contents of the cl file got inserted into the command line after the name of the ashell executable but before the which was on the original command line.
The other thing to note here is that the cl file must have the same name as the A-Shell executable and be in the same directory. If you have only one such special need, then it can probably share the same A-Shell executable and directory as your regular A-Shell users (since the regular users, at least under Windows, would presumably always be passing one or more -switches on the A-Shell command line, and thus would not use your .cl file.) But if you have need for multiple .cl files, or you are launching A-Shell under UNIX with no switches at all, then you will have to create one or more copies of (or links to) your A-Shell executable, each of which can then have it's own .cl file.
