On 23/05/18 00:57, J. Lewis Muir wrote:
On 05/22, Johnson, Andrew N. wrote:
Try using forward slashes instead of back-slashes, and also enclose the whole file path inside double quotes.
Bingo! That worked! Thank you!
Is this practice generally recommended for all Windows pathnames in
an EPICS context? Perhaps I should narrow this to all pathnames that
do not start with the pathname component separator (i.e., slash or
backslash)? I'm not sure. The idea is to avoid breaking any Windows
commands that take options that start with a slash and might get
confused. (?) But maybe if all pathnames eventually get turned into
absolute pathnames, everything works out. I've been faithfully using
the backslash to separate path components, but I noticed that a lot
of the pathnames generated by the EPICS build system include slashes,
so many of the pathnames end up containing a mix of backslashes and
slashes; it looks horrible, but it seems to work (except for msi).
Say I'm configuring the asyn EPICS module in <asyn>\configure\RELEASE,
is it better to set "SUPPORT=C:/opt/epics-module" and
"EPICS_BASE=C:/opt/epics-base" rather than using the normal Windows
backslash path component separator? For me, I think it's going to
be essential since I'd like to use macros in the file directive in a
template substitution file, and as your suggestion has shown, pathnames
must use backslashes, not slashes, in order for msi to work!
What about in <EPICS Base>\startup\win32.bat? I'm guessing everything
in there should still be using the backslash because all of those values
are being interpreted by Windows programs. Although, just looking at it
again, I see in the optional environment variables section commented out
lines like "set HOME=c:/users/jba". Maybe that's just for use with a
Cygwin program, though; I don't know.
The windows system can use forward - slashes when dealing with file
names (like opening a file).
This is documented here:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx
My conclusion is, that C:/something should work, as long as the length of the
path stays below MAX_PATH.
BTW, it also worked without the double quotes. This is consistent with
the template file syntax at:
https://epics.anl.gov/base/R3-14/12-docs/AppDevGuide/node7.html#SECTION007220000000000000000
which says:
The file name may appear inside double quotation marks; these are
required if the name contains any characters that are not in the
following set, or if it contains environment variable macros of the
form ${ENV_VAR_NAME} which are to be expanded before the file is
opened:
a-z A-Z 0-9 _ + - . / \ : ; [ ] < >
Since the pathname didn't contain any characters outside of the above
set, and since it didn't contain an environment variable macro of the
specified form, I concluded that double quotes were not needed.
Thanks!
Lewis
- Replies:
- Re: msi "Could not open" error on Windows with file absolute path J. Lewis Muir
- References:
- msi "Could not open" error on Windows with file absolute path J. Lewis Muir
- Re: msi "Could not open" error on Windows with file absolute path Johnson, Andrew N.
- Re: msi "Could not open" error on Windows with file absolute path J. Lewis Muir
- Navigate by Date:
- Prev:
Re: Is it possible to make an IOC for an HTTP device? Rod Nussbaumer
- Next:
Re: xxxRecord.c warning about epicsFloat64 to float conversion Ralph Lange
- 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
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: msi "Could not open" error on Windows with file absolute path J. Lewis Muir
- Next:
Re: msi "Could not open" error on Windows with file absolute path J. Lewis Muir
- 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
2020
2021
2022
2023
2024
|