On 08/28/2018 11:53 AM, Kasemir, Kay wrote:
> Looking further, the difference in pvget seems to be that a plain
> pvget ThePV now always seems to be the same as pvget -r
> 'field(value)' ThePV
>
> That works for most normative types that have a "value" as a
> top-level field, but can of course fail for a custom structure.
>
> In the past, pvget was more lenient. Maybe it checked the structure
> description, and if there's no "value", it would drop back to
> performing a "-r field()" request?
Last year Michael changed the pvget and pvput tools to use his new
pva/client.h API, but I don't see any evidence that he changed the
default pvRequest string, "field(value)" seems to have always been the
default. It may be though that if you didn't provide one with -r it just
sent an empty structure.
> I could argue either way:
>
> a) "pvget" without "-r .." should assume that we're reading a
> normative type, i.e. use "field(value)" and fail if there is no
> value.
> b) "pvget" should get something. First try "value", but if the PV
> info doesn't show a value field, just dump everything.
What does your older pvget show for its help text? The new one tells us
that it defaults to using 'field(value)', but this change in behaviour
looks like a regression now that you point it out.
> tux% pvget -h
>
> Usage: pvget [options] <PV name>...
>
>
> options:
> -h: Help: Print this message
> -V: Print version and exit
> -r <pv request>: Request, specifies what fields to return and options,
> default is 'field(value)'
> -w <sec>: Wait time, specifies timeout, default is 3 seconds for
> get, inf. for monitor
> -t: Terse mode - print only value, without names
> -i: Do not format standard types (enum_t, time_t, ...)
> -m: Monitor mode
> -p <provider>: Set default provider name, default is 'pva'
> -v: Show entire structure
> -q: Quiet mode, print only error messages
> -d: Enable debug output
> -F <ofs>: Use <ofs> as an alternate output field separator
> -f <input file>: Use <input file> as an input that provides a list PV
> name(s) to be read, use '-' for stdin
> enum format:
> -n: Force enum interpretation of values as numbers (default is enum string)
>
> example: pvget double01
I have added a link to this thread as a discussion point on the agenda
for next week. It would be helpful if you could have temporarily modify
your server to print out the pvRequest that it gets from the older pvget
just to confirm whether pvget used to send an empty object.
Thanks,
- Andrew
--
Arguing for surveillance because you have nothing to hide is no
different than making the claim, "I don't care about freedom of
speech because I have nothing to say." -- Edward Snowdon
- Replies:
- Re: "Invalid request" for simply "pvget ThePV" when all other requests seem fine Kasemir, Kay
- References:
- "Invalid request" for simply "pvget ThePV" when all other requests seem fine Kasemir, Kay
- Re: "Invalid request" for simply "pvget ThePV" when all other requests seem fine Andrew Johnson
- Re: "Invalid request" for simply "pvget ThePV" when all other requests seem fine Kasemir, Kay
- Navigate by Date:
- Prev:
Re: "Invalid request" for simply "pvget ThePV" when all other requests seem fine Kasemir, Kay
- Next:
Re: "Invalid request" for simply "pvget ThePV" when all other requests seem fine Kasemir, Kay
- 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: "Invalid request" for simply "pvget ThePV" when all other requests seem fine Kasemir, Kay
- Next:
Re: "Invalid request" for simply "pvget ThePV" when all other requests seem fine Kasemir, Kay
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
<2018>
2019
2020
2021
2022
2023
2024
|