Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 454383 - RFE: "yum search" should use a "large" width terminal by default, not an 80 char wide one
Summary: RFE: "yum search" should use a "large" width terminal by default, not an 80 c...
Alias: None
Product: Fedora
Classification: Fedora
Component: yum
Version: 9
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Seth Vidal
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2008-07-08 04:50 UTC by James Hunt
Modified: 2014-01-21 23:03 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2008-07-22 13:42:02 UTC

Attachments (Terms of Use)

Description James Hunt 2008-07-08 04:50:15 UTC
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):


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:

Comment 1 James Antill 2008-07-08 06:56:46 UTC
 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:

Comment 2 James Hunt 2008-07-08 20:52:50 UTC
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



Comment 3 James Antill 2008-07-08 21:53:21 UTC
 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.

Comment 5 James Antill 2008-07-22 13:42:02 UTC
 Given your usage of repoquery to solve the problem I'm just going to close this
 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.

Note You need to log in before you can comment on or make changes to this bug.