Experimental Physics and
Industrial Control System

Michael Davidsaver via Core-talk <core-talk at aps.anl.gov> · Fri, 29 Jan 2021 11:07:56 -0800

I finally got around to executing a small project which has been on my mind
for quite awhile now.  This has the potential to be a high visibility change,
so I want to run it past a wider audience.  (since so few people watch PRs)

Does this seem like a worthwhile change?

https://github.com/epics-base/epics-base/pull/102

The goal is to make it possible to write IOC shell scripts which don't depend
on the current directory.  eg. so that either:

> ./bin/linux-x86_64/myioc iocBoot/iocblah/st.cmd

or

> (cd iocBoot/iocblah && ../../bin/linux-x86_64/myioc st.cmd)

will work.

To do this, the PR adds three new automatic iocsh variables (not environment):
TOP, EPICS_EXEC_DIR, and IOCSH_SCRIPT_DIR.

(Variable names are provisional)

EPICS_EXEC_DIR will be the directory containing the current executable.
TOP will _default_ to "${EPICS_EXEC_DIR}/../..".  TOP set from eg. envPath
will take precedence.

IOCSH_SCRIPT_DIR will be the directory containing the current script file.
I think this could have interesting implications since it takes into
account nested scripts.  So eg. a script fragment containing

> dbLoadRecord("${IOCSH_SCRIPT_DIR}/../../db/blah.db", ...

would load the same .db file if run as

> <myscript.cmd

or

> <somedir/myscript.cmd

or

> <${SOME_MODULE}/db/myscript.cmd

The idea being that modules which have complicated setup could install
self-contained script fragments.  eg. not depending on specific variable
names in RELEASE

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System