Bug 439290 - 'rpm -q nonexistant' should display errors on stderr, not stdout
'rpm -q nonexistant' should display errors on stderr, not stdout
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: rpm (Show other bugs)
4.4
All Linux
medium Severity medium
: rc
: ---
Assigned To: Panu Matilainen
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-03-27 18:00 EDT by Jan Schaumann
Modified: 2009-02-05 08:40 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-12-12 02:55:14 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Proposed patch (600 bytes, patch)
2008-12-11 06:24 EST, Olivier Fourdan
no flags Details | Diff

  None (edit)
Description Jan Schaumann 2008-03-27 18:00:04 EDT
Description of problem:
$ rpm -q nonexistant 2>/dev/null
package nonexistant is not installed
$ 

I would have expected that message to go to /dev/null.
Comment 2 Olivier Fourdan 2008-12-11 06:24:19 EST
Created attachment 326604 [details]
Proposed patch

The message comes from rpmQueryVerify() in lib/query.c:

    rpmError(RPMERR_QUERYINFO, _("package %s is not installed\n"), arg);
    
The value RPMERR_QUERYINFO used here is defined in rpmio/rpmerr.h as:

    RPMERR_QUERYINFO    = _nm(137),

RPMERR_QUERYINFO is being used only in rpmQueryVerify() for the following messages:

    rpmError(RPMERR_QUERYINFO, _("no packages\n"));
    rpmError(RPMERR_QUERYINFO, _("unknown tag: \"%s\"\n"), a);
    rpmError(RPMERR_QUERYINFO, _("group %s does not contain any packages\n"), arg);
    rpmError(RPMERR_QUERYINFO, _("no package triggers %s\n"), arg);
    rpmError(RPMERR_QUERYINFO, _("malformed %s: %s\n"), "pkgid", arg);
    rpmError(RPMERR_QUERYINFO, _("no package matches %s: %s\n"),
    rpmError(RPMERR_QUERYINFO, _("malformed %s: %s\n"), "hdrid", arg);
    rpmError(RPMERR_QUERYINFO, _("no package matches %s: %s\n"), "hdrid", arg);
    rpmError(RPMERR_QUERYINFO, _("no package matches %s: %s\n"), "fileid", arg);
    rpmError(RPMERR_QUERYINFO, _("no package matches %s: %s\n"), "tid", arg);
    rpmError(RPMERR_QUERYINFO, _("no package requires %s\n"), arg);
    rpmError(RPMERR_QUERYINFO, _("no package provides %s\n"), arg);
    rpmError(RPMERR_QUERYINFO, _("file %s is not owned by any package\n"), fn);
    rpmError(RPMERR_QUERYINFO, _("invalid package number: %s\n"), arg);
    rpmError(RPMERR_QUERYINFO, _("record %u could not be read\n"), recOffset);
    rpmError(RPMERR_QUERYINFO, _("package %s is not installed\n"), arg);

And each time the return value is set to 1. So the message accompanying an error status should be sent to stderr and not stdout.

The proposed fix is to change RPMERR_QUERYINFO to _em(137) so all messages are treated as error messages and thus sent to stderr.

The drawback is that this is changing the behavior of "rpm -q", so this will break for all script that rely on the current behavior and expect messages from stdout.
Comment 3 Jan Schaumann 2008-12-11 11:53:33 EST
> The proposed fix is to change RPMERR_QUERYINFO to _em(137) so all messages are
> treated as error messages and thus sent to stderr.
> 
> The drawback is that this is changing the behavior of "rpm -q", so this will
> break for all script that rely on the current behavior and expect messages from
> stdout.

Just to clarify:
"rpm -q" should go to stdout if no errors are encountered.  Ie, if I'm querying for information and the information is found, it should to stdout.  If I'm querying for information and the information is NOT found, then the error message should go to stderr.

This is not terribly important, but it would be more consistent with regular unix behaviour.  Whether or not it's worth breaking the old behaviour (and I understand that others may rely on that), I can't judge.
Comment 4 Panu Matilainen 2008-12-12 02:55:14 EST
While I completely agree that rpm's behavior here is wrong, RHEL (4 or any other released version) is not the place to change it, it would only break scripts and introduce incompatibilities where such things are not expected or wanted. NAK.

FWIW, this is something upstream is aware of and would like to fix eventually, *when* it will happen is an entirely different question as it would be a big incompatibility in 10+ years of behavior (incorrect as it is)
Comment 6 Panu Matilainen 2009-02-05 08:40:45 EST
Just FYI, there's now an upstream tracker for this very issue: http://rpm.org/ticket/31

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