Hi Eric,
On 02/27/2014 11:49 AM, Eric Norum wrote:
> Seems reasonable — make sure to update the app dev guide, too….
>
> On Feb 27, 2014, at 9:23 AM, Andrew Johnson <[email protected]> wrote:
>
>> Hi Eric,
>>
>> Should the epicsEnvSet iocsh command be expanding escaped characters in
>> the value string before it calls the libCom epicsEnvSet() routine?
>> That's a very simple change which I think might be appropriate in 3.15:
>>
>> === modified file 'src/libCom/iocsh/libComRegister.c'
>> --- src/libCom/iocsh/libComRegister.c 2014-02-21 21:49:15 +0000
>> +++ src/libCom/iocsh/libComRegister.c 2014-02-27 17:18:18 +0000
>> @@ -105,6 +105,7 @@ static void epicsEnvSetCallFunc(const io
>> fprintf(stderr, "Missing environment variable value argument.\n");
>> return;
>> }
>> + dbTranslateEscape(value, value); /* in-place is safe */
>> epicsEnvSet (name, value);
>> }
>>
>>
>> - Andrew
>>
>> On 02/27/2014 08:57 AM, Eric Norum wrote:
>>> I see that I was in error -- it appears that it is only possible to have
>>> a newline in a prompt by passing it in as an environment variable from
>>> the shell.
Hmm, on second thoughts this might cause issues with the Windows path
separator '\'. The convertRelease.pl script already doubles them in the
generated envPaths file, presumably because the iocsh cd command on
Windows needs double-backslashes (or single forward-slashes) to work:
D:\epics\AD2>softIoc
epics> pwd
D:\epics\AD2
epics> cd D:\epics
Invalid directory path, ignored
epics> pwd
D:\epics\AD2
epics> cd D:/epics
epics> pwd
D:\epics
epics> cd D:\\epics\\AD2
epics> pwd
D:\epics\AD2
epics>
This means that something is already translating some escapes in the
command-line, so if I apply this patch we'll be double-translating the
envPaths values, which would be really annoying (the above softIoc does
not have the patch applied).
Ugh, it happens in macLib (I should have guessed):
macCore.c:
/* handle escaped characters (escape is discarded if in name) */
if ( *r == '\\' && *( r + 1 ) != '\0' ) {
if ( v < valend && !discard ) *v++ = '\\';
if ( v < valend ) *v++ = *++r;
}
It sometimes discards a leading '\' but never attempts to translate the
following character at all, so macLib is recognizing shell escapes,
whereas dbTranslateEscape() recognizes C-language escapes.
The macLib code supposedly does not strip back-slashes that are inside
quotes, so the above cd examples don't require doubled back-slashes if I
quote the path argument:
epics> cd "D:\epics"
epics> pwd
D:\epics
epics>
epics> cd "D:\epics\AD2"
epics> pwd
D:\epics\AD2
However that seems to contradict what I said above about the envPaths
file, why do we escape the back-slashes there? It turns out that the
behaviour is different if the value comes from an environment variable:
epics> epicsEnvSet EPICS_BASE "D:\epics\mirror-3.15"
epics> epicsEnvShow EPICS_BASE
EPICS_BASE=D:\epics\mirror-3.15
epics> cd $(EPICS_BASE)
Invalid directory path, ignored
epics> cd "$(EPICS_BASE)"
Invalid directory path, ignored
epics> epicsEnvSet EPICS_BASE "D:\\epics\\mirror-3.15"
epics> epicsEnvShow EPICS_BASE
EPICS_BASE=D:\\epics\\mirror-3.15
epics> cd $(EPICS_BASE)
Invalid directory path, ignored
epics> cd "$(EPICS_BASE)"
epics> pwd
D:\epics\mirror-3.15
epics> echo "$(EPICS_BASE)"
D:epicsmirror-3.15
That is still without doing any translation in epicsEnvSet (the echo
command *does* call dbTranslate() on its argument before printing it
though). It seems that quotes do *not* protect back-slashes that are
found in an environment variable value, although they do protect them in
a literal string:
epics> epicsEnvSet E "[\] [\\] [\\\] [\\\\]"
epics> epicsEnvShow E
E=[\] [\\] [\\\] [\\\\]
epics> echo "$(E)"
[] [] [] [\]
epics> echo "[\] [\\] [\\\] [\\\\]"
[] [\] [\] [\\]
That's just weird, and tells me that we're doing something wrong
somewhere. I'm not going to add translation to epicsEnvSet until we've
fixed whatever that is.
- Andrew
--
Advertising may be described as the science of arresting the human
intelligence long enough to get money from it. -- Stephen Leacock
- Navigate by Date:
- Prev:
Jenkins build is back to normal : epics-base-3.15 #42 APS Jenkins
- Next:
Build failed in Jenkins: epics-base-3.14-win32s #1 APS Jenkins
- Index:
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:
[Merge] lp:epics-gateway into lp:~info-martin-konrad/epics-gateway/epics-gateway-putlog Martin Konrad
- Next:
Build failed in Jenkins: epics-base-3.14-win32s #1 APS Jenkins
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
<2014>
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|