Documentation:

The wrapper operates by turning all inputs into strings. Parameter values are parsed from the inputted info by strsplit, using '=' as a delimiter. Consequently, anything without '=', that is not 'list', 'help', 'exit' or 'go' is not understood, and is passed straight through to the operating system.
Parameter settings which expect a number of values (e.g. setting a plot range, selecting some task options) are comma separated (WITH NO SPACES! - although this is simple to change), and strsplit is run again on the parameter, using ',' as the delimiter.

Quotes are not expected (eg. using in='mydatafile.icor'), or understood. Using quotes will return an error message.

For tasks which generate an output file, other than plots, or text outputs, data are generally saved using the IDL 'SAVE' command. Similarly, data which is being recalled from a file use the 'RESTORE' command. The name of the file is generally user-specified, however the name of the varible being saved helps to indicate what kind of data is actually saved. For example, variables holding data which is known to be a spectrum (output from corposonoff for example), are called 'DATA_SPECTRUM', although others exist e.g. data_cal, data_bon etc. (see code for icred_corposonoff.pro for many other examples). These names are HARDWIRED. They can be changed, but it will be an ugly task to do so, since it will be important to make sure that the changes are made consistent with other icred_<taskname>.pro programs. Personally, I think this is a bit ugly, but I cant think of a better way.

The organisation of icred is split into three levels:
1). the command interpreter: icred_interpreter.pro
This is the system which recieves all command inputs. it decodes inputs and selects tasks, parses parameter inputs and also runs the 'go', 'list' and 'help' commands.
It does no error checking, for example to see if the parameter inputs are sensible (e.g. it does not check if an x-range has been entered as 'chicken', rather than a more understandable range of say 10,20).

2) the task decoders: icred_<taskname>.pro
once 'go' is typed, the interpreter sends the current parameter settings (via a structure called 'paramlist') to the task decoders. These do error checking at some level, although this needs to be improved. Apart from checking to see that a requested input file exists, or that the requested options are understandable, no other checking is done. Yet.
Once all the input parameters make sense, a command is issued to run the existing ICorr software.

3) ICorr software.
This is the stuff that already exists, they also do error checking.

Other tasks or important commands:
GO: The general 'go' command sends the existing parameter listing to the decoders, which then initiate the execution of the ICorr software.

Help: This has a two-level response. A generic listing of existing implemented tasks and a brief description can be obtained with simply 'help', along with some other general syntax info. More task-specific info can be obtained by typing 'help=<taskname>', where the tasknames of the existing ICorr software are preserved (e.g. using 'corlist' still does what 'corlist' always did).

List: This lists the parameters for the current task, and the current settings.

Exit: This quits totally out of ICRED and IDL.

Other functions:
There are two small programs which are used to write, and recall previous parameter settings. These are 'writerecall.pro' and 'readrecall.pro'. Every time a task parameter is modified, the entire parameter list is sent to an archive file (called ICRED.arch). Every time a new task is selected, the archive file is read to recall the last parameter settings.