Commands using files should utilize new filename parser #1164
Comments
jphickey
added a commit
to jphickey/cFE
that referenced
this issue
Mar 3, 2021
For commands containing file names, replace the call to CFE_SB_MessageStringGet() - which is just a basic copy - to the new filename-aware function CFE_FS_ParseInputFileName(). This means that the default pathname/extension logic is applied here too and only a "basename" is strictly necessary, although if a full/absolute path is given, it will be used as is.
jphickey
added a commit
to jphickey/cFE
that referenced
this issue
Mar 16, 2021
For commands containing file names, replace the call to CFE_SB_MessageStringGet() - which is just a basic copy - to the new filename-aware function CFE_FS_ParseInputFileName(). This means that the default pathname/extension logic is applied here too and only a "basename" is strictly necessary, although if a full/absolute path is given, it will be used as is.
jphickey
added a commit
to jphickey/cFE
that referenced
this issue
Mar 16, 2021
For commands containing file names, replace the call to CFE_SB_MessageStringGet() - which is just a basic copy - to the new filename-aware function CFE_FS_ParseInputFileName(). This means that the default pathname/extension logic is applied here too and only a "basename" is strictly necessary, although if a full/absolute path is given, it will be used as is.
jphickey
added a commit
to jphickey/cFE
that referenced
this issue
Mar 16, 2021
For commands containing file names, replace the call to CFE_SB_MessageStringGet() - which is just a basic copy - to the new filename-aware function CFE_FS_ParseInputFileName(). This means that the default pathname/extension logic is applied here too and only a "basename" is strictly necessary, although if a full/absolute path is given, it will be used as is.
astrogeco
added a commit
that referenced
this issue
Mar 29, 2021
Fix #1164, use FS file name parser for commands
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is your feature request related to a problem? Please describe.
Issue #981 + PR #1156 introduces a new FS utility API to parse a filename which is aware of the expected path and extension, and will default to these if unspecified in the input. The initial PR only applies it to ES startup script.
But this creates an inconsistency; now you can put just a basename e.g.
ci_labin the startup script, but passing the same string as the filename toCFE_ES_START_APP_CCcommand will not work, which doesn't seem right.Describe the solution you'd like
For consistency in operation CFS should also employ the same filename parser in all commands that accept a filename.
Additional context
It is (intentionally, by design) fairly trivial to update a current call to
CFE_SB_MessageStringGet()to use the filename-aware alternative instead.The only minor issue/concern is that the new function has more input validation than
CFE_SB_MessageStringGet()does, so it is more important to check the return status. So doing this generally introduces another check + path to generate the error event, so a UT test case needs to be added. But that's about it.Requester Info
Joseph Hickey, Vantage Systems, Inc.
The text was updated successfully, but these errors were encountered: