# Different exit-values `glsa-check -t affected` returns `6` when there are affected-packages. `glsa-check -t -v affected` returns `0` Error is here [https://github.com/gentoo/portage/blob/master/bin/glsa-check#L419] the return-code 6 is only given, the `verbose`-flag is not set. The indent is one level to deep. # No exit-value in list-mode `glsa-check -l affected` returns `0` in any case. Even worser: the package-listing is printed to `std-out`, and the legend at the bottom is printed to `std_err`. The other way round would be more sensible. Reproducible: Always
Created attachment 920152 [details, diff] Patch to make glsa-check a more consistent.
(In reply to Micha Glave from comment #0) > # Different exit-values > > `glsa-check -t affected` returns `6` when there are affected-packages. > `glsa-check -t -v affected` returns `0` > > Error is here > [https://github.com/gentoo/portage/blob/master/bin/glsa-check#L419] the > return-code 6 is only given, the `verbose`-flag is not set. > The indent is one level to deep. > > # No exit-value in list-mode > `glsa-check -l affected` returns `0` in any case. The indentation change seems reasonable. > Even worser: the package-listing is printed to `std-out`, and the legend at > the bottom is printed to `std_err`. The other way round would be more > sensible. This change would break anyone who relies on the existing behavior. I don't think we should change it.
(In reply to Micha Glave from comment #0) > Even worser: the package-listing is printed to `std-out`, and the legend at > the bottom is printed to `std_err`. The other way round would be more > sensible. The standard interface for a command that produces a textual description of the information that has been queried, is for the desired information to be sent to stdout and, often, for any unnecessary e.g. debug information to be sent to stderr. The package listing ***must*** go to stdout. The legend would, with many programs, be printed to stderr. I understand that Zac is concerned about people relying on existing behavior. I'm not focused on that (I think that if a design is bad, it should be possible to change it). I'm just saying, that the proposed change is not a good proposal. The existing interface is good, and correct. The proposal is a bad interface and I'm unsure why you believe the proposal is "more sensible". (The point about the return code is entirely valid and correct. The manpage documents that an exit code of 6 denotes "System is affected by some GLSAs", and the program is failing to do so. Anyone relying on the existing behavior is simply in an erroneous state.)
(In reply to Eli Schwartz from comment #3) > The standard interface for a command that produces a textual description of > the information that has been queried, is for the desired information to be > sent to stdout and, often, for any unnecessary e.g. debug information to be > sent to stderr. > > The package listing ***must*** go to stdout. The legend would, with many > programs, be printed to stderr. > > I understand that Zac is concerned about people relying on existing > behavior. I'm not focused on that (I think that if a design is bad, it > should be possible to change it). I'm just saying, that the proposed change > is not a good proposal. The existing interface is good, and correct. The > proposal is a bad interface and I'm unsure why you believe the proposal is > "more sensible". In my case, I used the command in a cronjob `/usr/bin/glsa-check -l -n -v -c affected`. To suppress daily mails with only the legend I added `2>/dev/null`. This way I will get no info, if the job failed, because the error-message will appear on the suppressed stderr. I switched from `-l` to `-t`, with this I can relay on the return code. So the first hunk of this patch, which swapped the stderr and stdout-message is no longer needed, if the 2nd hunk with the corrected indention would be applied upstream.
