Brock, I have read the proposal and reviewed the needs for the GUI. It looks fine. I want to ask for two more things which will be necessary.
1. Would it be possible to add authority to the search result, so from which authority the search comes. I might be wrong and maybe this is already the case. 2. The status of the package which is the result of the search. So basically if the user is looking for: pkg search /usr/bin/bash How the user will know what packages are already installed on the system from the search result. The per package result call to the api could do the trick, but I am not sure about costs of such call. best Michal Brock Pytlik wrote: > Michael Schuster wrote: >> On 01/30/09 13:05, Brock Pytlik wrote: >>> Michael Schuster wrote: >>>> 1) I see you mixing short and long options. Is that necessary? >>> There are a limited number of letters, and a lot of pkg subcommands. >>> To attempt to reduce conflicts, I used long options for rare options. >>> Mostly, I closed my eyes and picked the first letter/string which >>> came to mind, I didn't put much thought into the option format at this. >>>> 2) if you need an option to limit the number of results, I see -n as >>>> the more obvious than -z. >>> -n has meanings in other contexts. I don't care what letter is >>> chosen, I chose -z for size >> do you mean "pkg search -n" is already taken, or that "pkg -n ..." is >> taken? > I mean pkg install -n, pkg uninstall -n, etc already have defined > meanings, and fairly important ones. I'm hesitant to create competing > associations in the users mind for that particular option. >>>> 3) the syntax for "find everything in /usr/bin" seems rather >>>> complex. From a previous discussion on this subject, shouldn't "pkg >>>> search /usr/bin" be able to "do the right thing" (since /usr/bin >>>> traditionally contains only files ... ;-) >>> Well, pkg search /usr/bin/* "does the right thing". >> are you considering shell globbing effects here, or just using >> unquoted notation for simplicity of this exchange? > Using the unquoted notation for simplicity. I can't really control the > shell globbing effects, and I think that defining our own '*' is > probably not the way to go. If there's an alternative, I'd love to hear it. >>>> 4) the expression syntax for and/or'ing stuff is ... ahem ... >>>> different from any other Solaris utility I know. Other precent to >>>> look at: find(1), snoop(1M), eg. >>> Well, from what I saw from glancing at the find man page, I didn't >>> see provisions for AND or OR, I only saw an implicit AND. >> expression -o expression. (including grouping with "()" - all very >> messy with shell escapes, etc.) >> >> I'm not saying it's ideal, but many unix people know it - it has been >> around for some time, after all ;-) > Unless I hear a large outcry, I don't think I'll be offering the -o > expression to mean "or". Especially not considering that -o may be an > option (a la pkg contents) to allow fine grained control over the output > categories. I think googlisms are a more reasonable style to take hints > from, especially given our goal of targeting a broader class of users. > Like I said, if there's a large outcry, I'll reconsider. > > Brock > _______________________________________________ > pkg-discuss mailing list > [email protected] > http://mail.opensolaris.org/mailman/listinfo/pkg-discuss _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
