Experimental Physics and
Industrial Control System

Alfio Rizzo via Tech-talk <tech-talk at aps.anl.gov> · Mon, 8 Mar 2021 07:14:07 +0000

Hi Michael,
At ESS we have the convention to have  in a particular position of the record name,
the '#' character for "internal" record, i.e. a record  which is used for instance for intermediate calculations, 
In practice this internal record should not be used outside the IOC,
i.e. no channel finder, no archiving , no alarm, no autosave, and so on.
We use as well the '-' and ':'  characters to separate some record name part, e.g.

"Normal" Record Name

Sys-Sub:Dis-Dev-Idx:Prop

"Internal" Record Name

Sys-Sub:Dis-Dev-Idx:#Prop

'#', ':', '- ' as well as '_' are 'legal' or 'illegal' characters ? 

Can we use them without the possible risk to have EPICS crashing in any future release ?

Thanks
Best
Alfio 

-----Original Message-----
From: Tech-talk <tech-talk-bounces at aps.anl.gov> On Behalf Of Michael Davidsaver via Tech-talk
Sent: Saturday, June 13, 2020 5:08 PM
To: Hu, Yong <yhu at bnl.gov>
Cc: EPICS Tech-Talk <tech-talk at aps.anl.gov>
Subject: Re: weird record names?

On 6/10/20 9:13 AM, Michael Davidsaver wrote:
> On 6/9/20 6:33 PM, Hu, Yong wrote:
>> Michael,
>>
>> When you say "restrictions", does that mean a newer version of EPICS IOC will fail to load a .db file in which a record name contains a "weird" character?
> 
> Eventually, yes.  That is what I'm considering.

cf. for a concrete proposal.  https://github.com/epics-base/epics-base/pull/78

>> If the IOC fails to load .db because it does not follow the new rules/restrictions, facilities that have already used "weird" characters will suffer badly when they upgrade EPICS base to a newer version. 
> 
> I recognize and want to avoid this.  
> Any new restriction would begin as a warning, and likely remain so for 
> a number of years.
> This would mainly serve as an early indication of names which would 
> cause problems in other contexts.  Record names which would be 
> impossible in link to (like "a b" below, or "123"), or which would 
> never parse as channel names (like "x.y").
> 
> 3.15.0.1 introduced a warning for record names containing " \"'.$".  
> These might now begin to be enforced.  And include "\t" for good 
> measure.
> 
> 
> 
>> Yong
>>
>>
>> On 6/8/20, 5:09 PM, "Tech-talk on behalf of Michael Davidsaver via Tech-talk" <tech-talk-bounces at aps.anl.gov on behalf of tech-talk at aps.anl.gov> wrote:
>>
>>     I'm looking to collect examples of epics record names in the wild.
>>
>>     This is an early step towards (maybe) adding restrictions on what
>>     characters a record name can contain, and in what positions.
>>     eg. restricting possible first and last characters.
>>
>>     In particular I'm looking for examples including characters
>>     beyond the usual alphanumeric separated by ':' or '-'.
>>     And in what positions they may (or may not) appear.
>>
>>     An example from the NSLS2 naming convention (for which I am have
>>     some responsibility).
>>
>>     > TST{evm:1D-DlyGen:31}Evt:Trig2-SP
>>
>>     Which is notable for containing "{" and "}" in the middle.
>>
>>
>>
>>     As background.  At present, records can be created with almost
>>     any characters in a name.
>>
>>     > record(ai, "a b") {}
>>     > record(ai, "x.y") {}
>>     > record(ai, "x\"") {}
>>
>>     However, record names including '.' can't be addressed and aren't
>>     very useful.  Further, names including spaces can't be targeted
>>     by links.
>>
>>     On the subject of links.  Dirk was surprised to find that
>>     the syntax for link parsing treats "[0]" as a record name,
>>     but "[0,1]" as a constant array.
>>
>>     
>> https://urldefense.com/v3/__https://bugs.launchpad.net/epics-base/*bu
>> g/1882520__;Kw!!P4SdNyxKAPE!TwNJ4RpksYZmN8YbfgjiN7Y3igc4486VOLcj-_1L1
>> KUqPcMdbvxVXH_bSrI3$
>>
>>     Rather than carving out another exception, I'd like to look at
>>     coding a general rule.
>>
> 

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System