EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: newline in IOCSH_PS1 value
From: Andrew Johnson <[email protected]>
To: Eric Norum <[email protected]>
Cc: EPICS core-talk <[email protected]>
Date: Thu, 27 Feb 2014 15:57:00 -0600
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  <20142015  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  <20142015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 16 May 2014 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·