Subject: |
Re: dbl output and record name aliases |
From: |
"Johnson, Andrew N." <[email protected]> |
To: |
EPICS Core-Talk <[email protected]> |
Date: |
Tue, 6 Jan 2015 17:48:52 +0000 |
On Jan 6, 2015, at 8:09 AM, Kasemir, Kay <[email protected]> wrote:
> IRMIS and the SNS 'crawler' that's derived from it go to quite some length parsing the st.cmd file and expanding macros in there to locate and finally parse the *.db files.
> Would be great to get more of that information from the IOC shell: record name, type, fields-defined-in-*.db file
>
> Could that be done by adding "-.." options to the existing dbl command?
I think a new command would make more sense, to avoid breaking existing scripts. There is nothing particularly special about the dbl and dbla commands that an external program couldn’t do, so if someone wants to extract database information they can write their own command(s) to do so, generating output in whatever format they wish (XML, JSON etc.). There is a JSON library (yajl) included in the 3.15 version of libCom so I would encourage use of that; my personal feelings about XML match Lewis Muir’s.
The output from the dbla command (DB List Aliases) is also suitable for machine parsing (the record names are space-separated, just ignore the ‘->’ between the alias name and its target record name), so Ralph could run both dbl and dbla and parse their output. The lines generated by something like 'dbl “*”, “NAME RTYP"' are not quite as parseable as this appends a comma to the first column and quotes the field values in the later columns, but it might be sufficient instead.
HTH,
- Andrew
> dbl -type -alias -fields
>
> The plain ASCII listing was OK for "dbl" that lists just record names, but it gets problematic if there are multiple columns of output.
> Since some sites have record names with ':', '{', .. in it, the format should handle those.
> If you're now thinking about adding a column for record type, next a column for alias name, later maybe columns for plain fields, 'info' fields, .., the format should allow adding columns without breaking parsers that were written before those new columns got added.
> XML or JSON already allow for all that, and would be better than creating a new format just for this record-list output.
>
> Thanks,
> Kay
>
> On Jan 6, 2015, at 4:03 AM, Ralph Lange <[email protected]>
> wrote:
>> Many installations use the output of a 'dbl' command on an IOC to create a "list of records on this IOC" file that gets scanned by some other service. (E.g. IRMIS, ChannelFinder, PV search databases, etc.)
>>
>> The 'dbl' command lists alias names as if they were records, with no distinction.
>> In many cases this is desired (e.g. for a PV search database), in other cases listing only names of "real" records would be preferred (e.g. for consistency checks, some ChannelFinder applications).
>>
>> Running 'dbl "" NAME' does create something that shows that extra information (both sides are equal for a record, else the left side is an alias for the right side) but obviously changes the output format.
>>
>> What would be the smartest way to allow both options and make everyone happy?
>> Should we go for an entirely new command with a new output format that maybe also shows the record type? ('dbl' with empty arg1 loops over the types, but does not show them.)
>> One-line-per-record-straight-ascii or XMLish?
>
>
- References:
- dbl output and record name aliases Ralph Lange
- Re: dbl output and record name aliases Kasemir, Kay
- Navigate by Date:
- Prev:
Re: dbl output and record name aliases Michael Davidsaver
- Next:
Conversion issues (analog device support with float type raw data) Ralph Lange
- 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:
Re: dbl output and record name aliases Michael Davidsaver
- Next:
Re: dbl output and record name aliases J. Lewis Muir
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
<2015>
2016
2017
2018
2019
2020
2021
2022
2023
2024
|