G'day Marko.
On 10/05/16 09:12, Nathan Scott wrote:
Hi Marko,
----- Original Message -----
Hi,
pmval and pmstore are the two clients which allow specifying the
targeted instances with -i. pmval, like most other clients also accept
arguments in this manner:
$ pmval kernel.all-load -i "'1 minute'"
I believe this to be the side-effect of GNU getopt(3) ... I personally
think this "flexibility" is sloppy, ill-conceived and not necessary.
I would much prefer to concentrate on the form ...
$ pmval -i "'1 minute'" kernel.all-load
which matches the original design and implementation (of Unix, not just
PCP).
So options can follow after non-option arguments. pmval also accepts
multiple -i options.
pmstore, on the other does not allow either. Only one -i and options
can't follow non-options.
I'm not a fan of the reordering part. The multiple options was a
conscious decision ... we expected the use of pmstore to be minimal
involving mostly singular metrics (the original use was to turn on pmcd
debugging on the fly and a (since retired) way to kill pmcd reliably).
Support for instances in pmstore(1) came later.
I'd be OK with pmstore(1) supporting multiple -i options, but note there
is only ONE value, so all instances would be set to the same value.
Also -i already accepts a list of instances, so there is a syntax that
works for both pmval and pmstore.
In the scripting case in particular, the value restriction may make
$ pmstore -i instance1 mymetric value1
$ pmstore -i instance2 mymetric value2
(or wrapped in a for/while-read loop) better than
# works now
$ pmstore -i instance1,instance2 mymetric value1_or_2
or
# needs pmstore change
$ pmstore -i instance -i instanc2 mymetric value1_or_2
I think it would be more consistent and also help with scripting in
certain scenarios if pmstore would be like pmval in this regard.
Or is there are practical reason for this difference? If not I think
I'll at least file an RFE.
For scripting in particular, I'd suggest stick to the form:
command [otions] arguments
as this will work reliably on ALL environments where PCP runs.
I have a vague memory of this being due to the need for pmstore to accept
negative values (like "-1") which get reordered by GNU getopts & presented
as an option ("1").
That was the original reason, I think, & if not for backward-compatibility
we'd probably have just documented "--" to end non-option arguments.
"--" in getopt(3) did not exist when PCP was written and still may not
exist on some platforms.
|