Bug 454383 - RFE: "yum search" should use a "large" width terminal by default, not an 80 char wide one
RFE: "yum search" should use a "large" width terminal by default, not an 80 c...
Product: Fedora
Classification: Fedora
Component: yum (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Seth Vidal
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-07-08 00:50 EDT by James Hunt
Modified: 2014-01-21 18:03 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-07-22 09:42:02 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description James Hunt 2008-07-08 00:50:15 EDT
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 02:56:46 EDT
 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 16:52:50 EDT
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 17:53:21 EDT
 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 09:42:02 EDT
 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.