On 4/20/12 9:20 AM, Danek Duvall wrote:
Philip Brown wrote:
Right now, searching for "file:vim" (or "file:anything", AFAIK) turns up
nothing. Given that, seems like it shouldnt be too hard to add in a
branch to the automagic, when there is a SINGLE modifier, (MOD:string) vs
MOD with more than one ':') along the lines of, "if there's no match, try
MOD as a different field".
Ah, I see, though I think I'd rather have separate option flags instead of
fancifying the colon-separated arguments. Something to think about, at
least.
Thanks,
Danek
Something else to think about:
What makes it more confusing, is that (at least for the things I am most
using pkg search for), the required user input, is in opposite order of
output.
Lacking more explicit documentation, I've been doing some blackbox
poking with inputs, which seems to yield things like the following:
If i'm searching for things such as pkg:/group/system/solaris-desktop
and related, the strictly correct longer form, would seem to be
pkg search 'set:pkg.fmri:group/system/*'
Yet the output line, has opposite order for first two fields.
INDEX ACTION VALUE
pkg.fmri set solaris/group/system/solaris/xxxxx
Similarly for other things such as filename searches, using the strict,
fuller search syntax, one appears to be expected to use
pkg search file:basename:zonestat
Yet this is the exact opposite of default output for the first two columns!
INDEX ACTION VALUE
basename file usr/bin/zonestat
Very confusing to the user. It would be difficult enough to understand,
with documentation on what these "index" vs "action" fields are, and
full samples of each. But we dont have that either, as mentioned previously.
It wouldnt be a big deal, if order of these modifiers was not significant.
Unfortunately, using
pkg search basename:file:zonestat
(which to any sane user, would be the 'natural' syntax for them to use,
given the output format) is currently invalid usage.
Worse of all, it is SILENTLY invalid. It does not throw an error, so the
user has no idea they are doing something "wrong"... they would most
likely erroneously assume, "gee, I guess there's no package containing
zonestat"
This is somewhat self correcting, in well known executable names, but
can lead to errors, when users are attempting queries of, "Hmm, I wonder
if solaris has this command yet?".
They will then falsely conclude, "no, it doesnt".
So this would be another point in favour of "fancifying" the argument
parsing, as you put it)
Or at the very least, throwing an error, when the user plugs in a value
for an "index" type, where that named index type does not exist.
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
