EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  <20202021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  <20202021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: Multiline statement in iocsh
From: "Johnson, Andrew N. via Tech-talk" <[email protected]>
To: "[email protected]" <[email protected]>
Date: Wed, 15 Jan 2020 18:31:01 +0000
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.

References:
Multiline statement in iocsh Saeed Haghtalab via Tech-talk
Re: Multiline statement in iocsh Ralph Lange via Tech-talk
Re: Multiline statement in iocsh Konrad, Martin via Tech-talk

Navigate by Date:
Prev: Re: Multiline statement in iocsh Konrad, Martin via Tech-talk
Next: Re: Killing caRepeater on Windows 10 Johnson, Andrew N. via Tech-talk
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  <20202021  2022  2023  2024 
Navigate by Thread:
Prev: Re: Multiline statement in iocsh Konrad, Martin via Tech-talk
Next: Fw: Multiline statement in iocsh Mark Rivers via Tech-talk
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  <20202021  2022  2023  2024 
ANJ, 15 Jan 2020 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·