2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 <2015> 2016 2017 2018 2019 2020 2021 2022 2023 2024 | Index | 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 <2015> 2016 2017 2018 2019 2020 2021 2022 2023 2024 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: Q: Portable way to construct a filename? |
From: | Ralph Lange <[email protected]> |
To: | EPICS Core-Talk <[email protected]> |
Date: | Mon, 21 Sep 2015 12:28:14 +0200 |
On 18/09/2015 22:20, Andrew Johnson wrote:On 09/18/2015 10:01 AM, Ralph Lange wrote:For use inside EPICS Base V3: What is a portable way to concatenate a directory name (received as iocShell command argument) and a filename (from a readdir() entry) into a path string that can be used in a fopen() call?There are no calls to readdir() from C/C++ code in Base yet, do you know that is portable? Some of the VxWorks and/or RTEMS file-systems might not support it although I believe the API itself is present. What is this for? I am very carefully reading man pages and try to only rely on the very minimum common denominator / POSIX2001 parts. Application: a new iocsh command. iocshLoadDir <pathname> <macros> This will allow to get rid of all the ugliness linked to sets of '< stcmd-snippet' lines with fixed names and orders inside a st.cmd file, replacing it with a standard mechanism that allows easy non-conflicting installation of st.cmd snippets by different apps, different system packages etc. The actual names, phases and related numbers are completely left to the users' conventions - base just provides the mechanism. Implementation is one additional C++ source file and its entry in the Makefile - doesn't change any existing code or functionality - no compatibility issues. (Could even be applied to 3.14 as an easy addition/patch.) I was also considering to add a test on the first argument to an IOC binary an the command line (the name of the command file to run), and call iocshLoadDir() instead of iocshLoad() if the argument is a directory. But that's less important than the command itself, and does add changes to an existing file, so ... well, maybe. What do you think? This and the rsrv-binds-to-specified-interface issue are the two things I intend to get into 3.15.3 (in addition to all fixes). Cheers, ~Ralph |