equery results are sometimes lengthly. The natural thing to do in unix with lengthly output from commands is to pipe it into less or, if you are looking for particular results, grep. But if you try to do this with equery, equery produces only abreviated output, not the output one would see if the output isn't sent to a pipe.
Now, I understand that the abbreviated output is useful when parsing the output via a program, but in that case the brief output should be enabled by a flag that the script specifies. Interactive use should default to interactive output format.
Steps to Reproduce:
equery uses firefox | less
[ Legend : U - final flag setting for installation]
[ : I - package is installed with flag ]
[ Colors : set, unset ]
* Found these USE flags for www-client/firefox-4.0-r3:
+ + alsa : Adds support for media-libs/alsa-lib (Advanced Linux Sound Architecture)
- - bindist : Flag to enable or disable options for prebuilt (GRP) packages (eg. due to licensing issues)
- - custom-optimization : Fine-tune custom compiler optimizations
+ + dbus : Enable dbus support for anything that needs it (gpsd, gnomemeeting, etc)
- - debug : Enable extra debug codepaths, like asserts and extra output. If you want to get meaningful backtraces see http://www.gentoo.org/proj/en/qa/backtraces.xml
+ + ipc : Use inter-process communication between tabs and plugins. Allows for greater stability in case of plugin crashes
Please report which gentoolkit version you are referring to.
Also, by default equery does turn on the --quiet option when output is detected to be connected to a pipe. I will look into disabling it and what other affects it will have.
rdmurray@hey:~>equery list gentoolkit
* Searching for gentoolkit ...
[IP-] [ ] app-portage/gentoolkit-0.3.0:0
That's not a bug, but a feature.
To have a verbose output through a pipe, use the '-N' option.
(See the manual for more details).
In my opinion it is a misfeature. That's why I filed this under 'feature request' rather than as a bug.
From a usability perspective, the default output of a primarily interactive command should be the interactive output. If a script (or a user writing a pipeline for a special purpose) wants the abbreviated form, they can pass the flag to change the behavior.
An example of the right way to handle this is the 'ls' command, Its only change in behavior is to put one filename per line instead of formatting it to multiple columns. This is reasonable, because it makes it easier to use grep but *does not lose any information*. equery, on the other hand, omits all kinds of information when run through a pipe. It would, for example, make sense to omit the "prefix" boilerplate when equery runs through a pipe. But IMO per-entry information should not be omitted unless that is asked for via a flag. The point is that just changing to running a command through a pipe should not *lose information* unless it is explicitly requested via a flag. It's that surprise factor that is the biggest problem. I see a screen full of info go by, but I'm only interested in a single flag (say), so I pipe it to grep to grab just that flag's info...and whammo, all I see is the flag name. Where'd the description go? This is even *way* more true when I pass it to less, since any time more than a screen full of info flies by the natural reaction of a unix command line user is to pipe it to less to see it a page at a time. Result: user frustration and annoyance. I shouldn't have to specify a special flag to get the same info I see when running the command with its default flags just because I passed it to less (or grep).
(Omitting the color information is of course fine, since most pipeline tools won't handle them correctly.)
Since this has been the behavior since the beginning, I'm very hesitant to change the default at this point. However, what I do think we should do is provide an EQUERY_DEFAULTS_OPTIONS that works in the same manner as EMERGE_DEFAULT_OPTIONS works for emerge. That way users who want to change the default behavior have a mechanism to do so without having to always specify the options.
I see this as something to target in the 0.3.1 release.