ago@devil ~ $ eix -I quassel [I] net-irc/quassel Available versions: 0.7.1 **9999 {X ayatana crypt dbus debug kde monolithic phonon postgres +server +ssl webkit} Installed versions: 0.7.1(19:49:41 14/11/2010)(X crypt dbus kde ssl -ayatana -debug -monolithic -phonon -postgres -server -webkit) Homepage: http://quassel-irc.org/ Description: Qt4/KDE4 IRC client suppporting a remote daemon for 24/7 connectivity. ago@devil ~ $ eix quassel -I [I] net-irc/quassel Available versions: 0.7.1 **9999 {X ayatana crypt dbus debug kde monolithic phonon postgres +server +ssl webkit} Installed versions: 0.7.1(19:49:41 14/11/2010)(X crypt dbus kde ssl -ayatana -debug -monolithic -phonon -postgres -server -webkit) Homepage: http://quassel-irc.org/ Description: Qt4/KDE4 IRC client suppporting a remote daemon for 24/7 connectivity. ago@devil ~ $ eix -e quassel [I] net-irc/quassel Available versions: 0.7.1 **9999 {X ayatana crypt dbus debug kde monolithic phonon postgres +server +ssl webkit} Installed versions: 0.7.1(19:49:41 14/11/2010)(X crypt dbus kde ssl -ayatana -debug -monolithic -phonon -postgres -server -webkit) Homepage: http://quassel-irc.org/ Description: Qt4/KDE4 IRC client suppporting a remote daemon for 24/7 connectivity. ago@devil ~ $ eix quassel -e No matches found. when I put -e after package, no matches found, but, with '-I' option or other, there aren't problems.
This is one of the fine points of eix' syntax which is hard to explain which is why the grammar for EXPRESSION is given on the manpage of eix (after Options for EXPRESSION; I admit that the manpage of eix is a mess which should be rewritten completely, but I have no time for it): A pattern (in your case "quassel") always ends an EXPRESSION. Anything after it is considered as the next EXPRESSION; if you do not concatenate two expressions with --and or --or, then --and is assumed (unless you set DEFAULT_IS_OR). This means in your examples: 1. eix -I quassel This has only one expression, namely "match for quassel and installed". 2. eix quassel -I Since quassel ends the first EXPRESSION, this is actually equivalent with eix quassel --and -I So you are actually matching against "quassel", and if that test is successfull, another test is performed which matches against "installed". If you would have set DEFAULT_IS_OR=true, then 2. would in fact mean something different, namely the same as eix quassel --or -I 3. eix -e quassel This is one EXPRESSIONS "match for exactly quassel". 4. eix quassel -e These are again two expressions, concatenated with --and (unless you set DEFAULT_IS_OR=true). So this is equivalent to eix quassel --and -e This means that two tests are performed, and only packages passing both are printed: The first test matches the name (non-exactly!) against "quassel", and the second test look whether the package name is (exactly!) the empty string.
That makes sense. But is it intuitive and user friendly?
(In reply to comment #2) > That makes sense. But is it intuitive and user friendly? It is powerful. Unfortunately, "user friendly" and "powerful" ar often orthogonal. There is a need to be able to look for complex expressions like eix -O --and --not '-(' -C 'kde*' --or --in-overlay sunrise '-)' and I know of several people using such things in complex scripts. So the expressions have to follow some rules. The other point is: There are no "intuitive" rules (this is what I always realize from people claiming windows be "intuitive": They just have accustomed to the rules which they have learnt over time; originally, these rules were not intuitive to them). To explain specifically for eix: Most people would intuitively expect that eix foo bar will list the packages matching foo *or* bar, while at the same time they would intuitively expect that a successive listing of conditions restricts the output even more. Of course, this intuition contradicts itself: It corresponds to setting DEFAULT_IS_OR to true or false. This is the reason why I introduced this variable: You can set what is intuitive to *you*, but there is not general "intuitive" rule for everybody in every useage. The alternative is either to formulate many special cases and exceptions (e.g. if two nonempty patterns are involved the default is "or" otherwise the default is "and", an -e without an expression refers to the previous expression etc.) or to be very strict and require that the user always types explicitly --and or --or. However, the former becomes a nightmare when you want to write a complex test - especially if parts of the arguments are automatically generated in some script, you need rather complex functions to generate the "intuitive" arguments - and the latter gives also unintuitive error messages and does not allow some "intuitive" shortcuts for "quick" calls of eix. So I simply think there is no solution which satisfies all needs. The eix way is to follow unix philosophy: There is a standard unix tool which in its syntax is in a way very similar to eix, namely "find". The usage of "find" is anything but intuitive, but it is not accidental that it never got replaced by something else. In fact, once you think about it, the syntax of "find" is rather logical (although it has some problems, e.g. if the top directory is called "--print"; eix works around some of these problems). Certainly, this solution is not perfect, but there is not perfect solution, and at least it corresponds to unix philosophy. For an "intuitive" eix, it would probably be more appropriate to have some simple GUI frontend.
I added now some more explanation to EXPRESSION in the manpage.
