Philip Brown wrote: > >Why? How do you know it's not file:::vim? What about "basename:file"? > >That could reasonably be "basename:file::" or "::basename:file". And > >given the way searching through set actions works, where the "key" is > >the value of the "name" attribute (so I can do a search for, say > >set:info.upstream-url:*gnu.org*), you can even have the key namespace > >overlap the action namespace. > > The same argument could be given against allowing > basename:vim -> ::basename:vim, couldnt it? > > "How do you know it isnt :basename::vim"? etc, etc.
That's a bug in our documentation. "Missing fields" should be expanded to something that indicates consecutive missing fields to the left as well as empty fields in other positions. > >I'm not saying I disagree entirely with you about needing something better > >than the colon-separated search argument, but given that's what we've got, > >there's not much more automagic we can do with the parsing. > > 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 _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
