Description of problem: Yum behaves inconsistently when using "search" seemingly to try and be helpful. However, it stops it from being fully usable in a standard Unix workflow. Version-Release number of selected component (if applicable): yum-3.2.16-2.fc9.noarch How reproducible: Every time. Steps to Reproduce: 1. Try something like : "yum search ddskk-xemacs" 2. *Then* try this : "yum search ddskk-xemacs|more" Actual results: "yum search ddskk-xemacs" returns a single line (may wrap in this description box though?): ddskk-xemacs.noarch : Daredevil SKK - Simple Kana to Kanji conversion program for XEmacs ...whereas "yum search ddskk-xemacs|more" returns *TWO* lines (note the way it is formatted)... ddskk-xemacs.noarch : Daredevil SKK - Simple Kana to Kanji conversion program : for XEmacs Expected results: Like all Unix/Linux tools, yum should behave sanely and consistently. I can understand in a way why it is doing what it is, but there are 2 problems: 1) you cannot use standard tools like "sort" with "yum search <re>|sort" since yum breaks "long" lines into multiple lines to be helpful such that you end up with "fragments" of lines to deal with (yes, you could write a hacky script to work around this). 2) It's actually less helpful that you think: my console is 152 characters wide, but "yum search <thing>|more" *always* wraps the text to be within 80 characters, so it's not even considering $COLUMNS. I suggest that the "intelligent folding" be removed or atleast give a --sane option so it plays nicely with stanard tools. Additional info:
The summary is always wrapped, it just defaults to an 80 char. wide "screen" if it can't find out a real value. We could look at $COLUMNS, if that was passed to sub-processes, but it isn't (try: perl -le 'print $ENV{"COLUMNS"}') so we can't. We could default to a "999,999,999" character wide screen, instead of 80 ... and that _might_ be the better behaviour in the general case. However for your particular usecase I'd _highly_ recommend using a few lines of python ... you can then sort the results as you wish and any future changes yum makes won't mess it up. Example search script here: http://permalink.gmane.org/gmane.linux.rpm.yum/12243
Hi James, The python code is interesting, but I think the best option for me is to use repoquery as that does exactly what I want (and expect :) repoquery -a --qf "%{name} : %{summary}" "*xemacs*"|sort -t: -k1,1|less Cheers, James.
Hey, whatever works for you is fine by me :) ... however you should note that "yum search" and a snippet like I pointed to is case insensitive. So if instead of "xemacs" you consider searching for "mysql", you'll miss a bunch of results with the repoquery method. I'm not sure if this is a bug or a feature of repoquery though, I expect not many people use it like you do above :). repoquery also currently takes about 2x the amount of time, atm. ... but I'll look at if I can fix that. Might be worth doing a pkg sort too.
Given your usage of repoquery to solve the problem I'm just going to close this WONTFIX. As I said, in theory we could make the default line length really big ... but that is suboptimal for if you do "yum blah | less" and is only correct in the grep case ... which we'd generally prefer people not do.