Re: Multiline statement in iocsh

["Johnson, Andrew N. via Tech-talk" <tech-talk@aps.anl.gov>]

On 1/15/20 9:40 AM, Konrad, Martin via Tech-talk wrote:
> On 1/15/20 10:31 AM, Saeed Haghtalab via Tech-talk wrote:
> > That’s right. I’ve put the comments in each line deliberately because
> > I think since startup script mostly contains the commands and 
> > configuration (and not code) with many arguments and macro
> > substitution, I think it makes sense to support inline comment in
> > multiline statement in this case which helps in readability a lot.
> In my experience comments tend to be wrong after a while. To me it
> sounds like we actually want support for named arguments [1].
The IOC shell was written at the time we were making it possible to run IOCs on non-VxWorks systems so we needed something to replace the VxWorks target shell that comes with that OS. The design was intended to be syntax-compatible with the VxWorks shell so
 startup script segments could be written that would work with both shells. Subsequently we have extended the capabilities of the IOC shell beyond what the VxWorks shell can do, but the IOC shell is present in VxWorks IOCs and can be used to run those scripts,
 so I'm not really concerned about maintaining strict compatibility.

It should be possible to add named arguments to the shell's command-line parser, if someone wants to try implementing that. The shell already knows all the argument names from the
iocshArg objects for the command, although those names are currently allowed to contain spaces and other characters. One issue with this might be any commands that already accept strings of the form
key=value since they might be stolen by the parser and not handed to the command.

Note that it is already possible to use named arguments, but you would have to have a script for each such command that knows the position of each argument. The st.cmd line for Saeed's command might look something like this:
> iocshLoad dbLoadRecords.cmd, "file-name=myDb.db, substitutions='P=prefix,R=suffix'"
That would call a script called dbLoadRecords.cmd that would contain
> dbLoadRecords $(file-name), $(substitutions)
Not really an improvement, so I don't actually recommend this as a solution. However it does echo Pete Jemian's suggestion to put arguments into variables, which
can help with readability. That doesn't work with the above case, but some of the Asyn commands or modules downstream of Asyn that have many arguments could be made more readable by putting at least some of the common arguments into variables, e.g. turning
 a block like this
> drvModbusAsynConfigure("UPS_X7_STR1","L0",0,4,1032,125,11,500,"EATON93PM")
> drvModbusAsynConfigure("UPS_X7_STR2","L0",0,4,1160,64,11,500,"EATON93PM")
> drvModbusAsynConfigure("UPS_X7_STR3","L0",0,4,1256,40,11,500,"EATON93PM")
> drvModbusAsynConfigure("UPS_X7_STR4","L0",0,4,1477,64,11,500,"EATON93PM")
into
> epicsEnvSet ups UPS_X7
> epicsEnvSet link-adr-fn "L0,0,4"
> epicsEnvSet poll-pm "500,EATON93PM"
>
> drvModbusAsynConfigure "$(ups)_STR1", $(link-adr-fn), 1032,125, 11, $(poll-pm)
> drvModbusAsynConfigure "$(ups)_STR2", $(link-adr-fn), 1160, 64, 11, $(poll-pm)
> drvModbusAsynConfigure "$(ups)_STR3", $(link-adr-fn), 1256, 40, 11, $(poll-pm)
> drvModbusAsynConfigure "$(ups)_STR4", $(link-adr-fn), 1477, 64, 11, $(poll-pm)

Another idea that occurs to me is that you could use macLib syntax to document your arguments, without having to set any variables beforehand, like this:
> dbLoadRecords $(file-name=myDb.db), 'P=prefix,R=suffix'
This requires that you not have environment variables set with names to the left of any of the '=' signs, and the argument value after the '=' sign can't contain a comma or close-parenthesis. You can even add comments, like this:
> dbLoadRecords $(file-name=myDb.db, comment___), 'P=prefix,R=suffix'
Of course since this makes the command-line longer it would probably help if the line could be broken across multiple lines, and now we're back to Saeed's original question. This isn't possible at the moment, but probably could be added if someone wanted to
 try that. I would want us to use the standard syntax with a back-slash immediately before the newline.

- Andrew
-- 
Complexity comes for free, Simplicity you have to work for.