Although there are a lot of possible A-Shell command lines switches, and it would be inconvenient to have to type them every time, there are multiple ways to store one or more sets of them in a file, to be invoked later without having to retype them. Under Windows, the simplest approach is to store them all in the properties of the icon(s). Under Unix, you can create multiple script files that contain different complete command lines.
Even with the above options, sometimes it is most convenient to be able to execute A-Shell simply by invoking the executable name (e.g. ashell.exe or ashw32.exe). For this kind of situation, we offer "cl" (command line) files. A cl file contains just the command line switches, not the name of the ashell executable. They work as follows.
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 (ashell.exe or ashw32.exe), 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 <inifile>" setting even when it is not possible to have it supplied explicitly on the A-Shell command line. An example may make this clearer.
Let's take the case of CGI, in which 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 would be where you have some kind of existing module that is capable of invoking arbitrary external commands of the form:
<command-executable-path> <file-arg>
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 <file-argument> 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 <file-argument>, 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 <file-argument> as its parameter, allowing you to then pass it on to an ASB program, using one of these basic techniques:
;myprog.do
:R
log myppn: ; you must log somewhere
run myapp $0 ; myapp will use LSTLIN 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 ashw32.cl would be:
<ashell path>\ashw32.exe -i c:\vm\miame\miame.ini myprog <file-arg>
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 <file-arg> 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 its own cl file.
