Merge ~dirk.zimoch/epics-base:FixShellCommands into ~epics-core/epics-base/+git/epics-base:7.0
Status: | Merged |
---|---|
Approved by: | Andrew Johnson |
Approved revision: | 4190f38db0d88264e2f88a7962880a6dfea09db6 |
Merged at revision: | f0bbae1767f56875beb6cad9fe3c9088725c7fa3 |
Proposed branch: | ~dirk.zimoch/epics-base:FixShellCommands |
Merge into: | ~epics-core/epics-base/+git/epics-base:7.0 |
Diff against target: |
349 lines (+96/-15) 12 files modified
modules/database/src/ioc/db/dbAccess.c (+10/-1) modules/database/src/ioc/db/dbBkpt.c (+12/-0) modules/database/src/ioc/db/dbNotify.c (+5/-1) modules/database/src/ioc/db/dbState.c (+6/-0) modules/database/src/ioc/db/db_test.c (+12/-0) modules/database/src/ioc/misc/dlload.c (+8/-3) modules/libcom/src/iocsh/iocsh.h (+7/-0) modules/libcom/src/iocsh/libComRegister.c (+28/-10) modules/libcom/src/osi/os/Darwin/osdEnv.c (+1/-0) modules/libcom/src/osi/os/default/osdEnv.c (+1/-0) modules/libcom/src/osi/os/iOS/osdEnv.c (+1/-0) modules/libcom/src/osi/os/vxWorks/osdEnv.c (+5/-0) |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Andrew Johnson | Approve | ||
Review via email: mp+355761@code.launchpad.net |
Commit message
Fix several ioc shell functions.
Description of the change
The functions 'echo', 'dlload', 'epicsParamShow', 'setIocLogDisable' and 'errlog' which are available in iocsh were missing in the vxWorks shell. Calling 'errlog' caused a crash because of a thread with that name. These functions have now been added to the vxWorks shell.
Several functions showed buggy behaviour or printed hard to understand error messages when being called without arguments.
* 'epicsEnvSet' without arguments used to set *NULL to *NULL causing problems later
* 'dbLoadDatabase' and 'dbLoadRecords' printed: "dbRead opening file (null)"
* 'dbap', 'dbb' and 'dbd' printed: "Record (null) not found"
* 'gft', 'pft' and 'tpn' printed: "Channel couldn't be created"
* 'dbtpn' printed: "dbtpn: No such channel" but without newline.
They all now print a "Usage: ..." message.
BTW: I found that all the tests for those functions did not include missing (NULL) mandatory string arguments. I suggest to add that case to the tests for every shell function.
Not fixed:
* 'var' is not available on the vxWorks shell but would be difficult to implement.
* 'epicsThreadSleep' called on the vxWorks shell without arguments sleeps for an unpredictable period. This is a problem of using double type arguments on the vxWorks shell.
Hi Dirk,
Good idea, a few comments about your specific changes though.
It's only the VxWorks shell (and I guess the RTEMS CEXP shell) that can pass in NULL pointers to some of these commands. Adding the NULL check to any osdEnv.c file except for libcom/ src/osi/ os/vxWorks/ osdEnv. c doesn't make too much sense to me.
I would prefer that we not print anything in dbStateCreate() which is also an API entry point for the dbState subsystem, just return NULL for a NULL input.
Your VxWorks dlload() routine needs a check for a NULL input argument...
Finally a few comments about your Usage messages: Parentheses are not required around arguments to VxWorks or iocsh commands, they're only needed for an IOC using CEXP on RTEMS, and the people who run such IOCs know about the requirement. Parentheses take longer to type and I'd rather we not imply they're needed when they aren't. The iocsh help output shows command usage without parentheses (which are allowed there too), although I wish it prefixed the full command with "Usage:" when shown with argumemts (like you do):
epics> help dbLoadDatabase
dbLoadDatabase 'file name' path substitutions
epics> help dbLoadRecords
dbLoadRecords 'file name' substitutions
epics> help dbb
dbb 'record name'
epics> help dbtpn
dbtpn 'record name' value
epics> help epicsEnvSet
epicsEnvSet name value
That help command only puts quotes around arguments that have spaces in their name, which is different than the requirements of the VxWorks shell (but that is how the iocsh parses arguments). Your use of double-quotes around string arguments shows they are required for VxWorks though, which is fine and correct.
Thanks,
- Andrew