Bug 439290 - 'rpm -q nonexistant' should display errors on stderr, not stdout
Summary: 'rpm -q nonexistant' should display errors on stderr, not stdout
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: rpm
Version: 4.4
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Panu Matilainen
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-03-27 22:00 UTC by Jan Schaumann
Modified: 2009-02-05 13:40 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-12-12 07:55:14 UTC
Target Upstream Version:
Embargoed:


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

Description Jan Schaumann 2008-03-27 22:00:04 UTC
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 11:24:19 UTC
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 16:53:33 UTC
> 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 07:55:14 UTC
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 13:40:45 UTC
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.