Philip Brown wrote:
Danek Duvall 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.
Hmm. after pondering this further, I'm thinking that I assumed a particular
reading of the manpage, whereas others were taking it another way.
I read "Missing fields are implicitly wildcarded."
as
"ANY missing field".
Whereas Danek, etc. are reading it as
"Missing [leading] fields are implicitly wildcarded".
If that stricter reading is going to rule, then first of all, the manpage
needs updating :)
Additionally, the whole "action type" vs "key" thing needs clarification.
Brock(?) mentioned that acceptible values are not mentioned in the
manpage... but even worse, the terms "action type" and "key" are not
explained at all either.
So basically, as a user, it makes no sense to me that
"file" == [action type]
whereas
path, basename are [key]s.
To me, for the last 20 years, the words "file", "path", and "basename" are
all normally on the same conceptual level. Separating them into different
areas, isnt making sense to me.
Completely lack of contextual explanation in the manpage, isnt making things
any easier there.
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
