Re: Octal escape sequence translation issue in base 7.0.6.1?

["Wlodek, Jakub via Tech-talk" <tech-talk at aps.anl.gov>]

Hi Mark,

We also recently ran into this configuring a Pilatus detector at NSLS2 with recent versions of base/areaDetector. Indeed, as Andrew said, the solution we found was to change "\030" to "\x18" which is the two digit hex equivalent.

Best,

Jakub

---

From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Andrew Johnson via Tech-talk <tech-talk at aps.anl.gov>
Sent: Tuesday, May 17, 2022 5:34 PM
To: tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
Subject: Re: Octal escape sequence translation issue in base 7.0.6.1?

 

Hi Mark,

On 5/17/22 4:17 PM, Mark Rivers via Tech-talk wrote:

Folks,

 

I just switched to using base 7.0.6.1 on my beamlines.  When I try to start a Pilatus detector I get this error:

 

# Set the input and output terminators.

asynOctetSetInputEos("camserver", 0, "\030")

Set EOS failed: camserver illegal eoslen 3

 

It appears that it is interpreting the escape sequence \030 as a string of 3 characters rather than as a single character.  Is this a bug in base 7.0.6.1 or a problem with my syntax?  This used to work fine with base 7.0.4, I have not changed anything.

I assume iocsh is using epicsString.h functions to interpret the escapes inside parameters, these changes appeared in EPICS 7.0.5:

Character Escape Changes

• The libCom routines epicsStrnRawFromEscaped() and dbTranslateEscape() declared in epicsString.h no longer accept octal escaped characters such as \123 or \41.
• The routine epicsStrnEscapedFromRaw() now generates hex excaped characters for unprintable characters such as \x1f.
• Hex escape character sequences \xXX must now contain exactly 2 hex digits.
• An escape sequence \0 now generates a zero byte in the raw string, but the other digits 1-9 should not appear after a back-slash.

These changes are to more closely follow the JSON5 standard, which doesn't support octal character escapes or the \a (Bel, \x07) escape sequence.

2-digit hex \xXX escapes should work fine on both sides of the change.

- Andrew

-- 
Complexity is free, it's Simplicity that takes work.