[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#927992: marked as done (Write errors and warnings to STDERR, don't hide them if not a tty)

Your message dated Fri, 26 Apr 2019 11:40:42 +0200
with message-id <20190426094042.roji26sdcgilsubw@crossbow>
and subject line Re: Bug#927992: Write errors and warnings to STDERR, don't hide them if not a tty
has caused the Debian Bug report #927992,
regarding Write errors and warnings to STDERR, don't hide them if not a tty
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
927992: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927992
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: apt
Version: 1.8.0
File: /usr/bin/apt-cache

In Unix/Linux we have STDOUT and STDERR. Please just use these two,
and don't invent "smarter ways."

Really really bad and this will come back to bite you one day:

You have a kind of message that is only shown if the user is on a tty.

You don't user the industry standard of sending it to STDERR,
You instead just hide it... if the user apparently isn't using a TTY.

One can't even pipe the output of your program to any other program,
expecting messages to go to STDERR. The message just disappears!

$ apt-cache show twitter-bootstrap
N: Can't select candidate version from package twitter-bootstrap as it has no candidate
N: Can't select versions from package 'twitter-bootstrap' as it is purely virtual
N: No packages found
$ apt-cache show twitter-bootstrap 2>&1|wc
      0       0       0

In fact I can think of no other program in the entire history of Unix
that has decided to do that.

If the user doesn't want the message he can just do 2> /dev/null. Or
2>&- . That's how we do things on Linux/Unix.

$ apt show twitter-bootstrap
Package: twitter-bootstrap
State: not a real package (virtual)
N: Can't select candidate version from package twitter-bootstrap as it has no candidate
N: Can't select versions from package 'twitter-bootstrap' as it is purely virtual
N: No packages found

Now experimenting with apt,

$ apt show twitter-bootstrap 2>&1 | nl -b a
     1
     2  WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
     3
     4  Package: twitter-bootstrap
     5  State: not a real package (virtual)
$ apt show twitter-bootstrap | nl -b a

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

     1  Package: twitter-bootstrap
     2  State: not a real package (virtual)

Aptitude is much more consistent,

$ aptitude show twitter-bootstrap | nl -b a
     1  Package: twitter-bootstrap
     2  State: not a real package
     3  Provided by: libjs-twitter-bootstrap (2.0.2+dfsg-10)
$ aptitude show twitter-bootstrap
Package: twitter-bootstrap
State: not a real package
Provided by: libjs-twitter-bootstrap (2.0.2+dfsg-10)

Anyway your idea of a tty is fine for you. But not for how many users
will use these programs. Thanks.

--- End Message ---
--- Begin Message --- 
On Fri, Apr 26, 2019 at 09:07:35AM +0200, Julian Andres Klode wrote:
> On Fri, Apr 26, 2019 at 11:02:42AM +0800, 積丹尼 Dan Jacobson wrote:
> > $ apt-cache show twitter-bootstrap
> > N: Can't select candidate version from package twitter-bootstrap as it has no candidate
> > N: Can't select versions from package 'twitter-bootstrap' as it is purely virtual
> > N: No packages found

As the 'N' indicates they are neither warnings nor errors. They are
notices. Hints for the reader – which means an interactive reader as
programmatic readers do not follow hints and worse tend to be very
confused by them.

A bit related to those tip-of-the-day and "Clippy" perhaps: Given no
previous message on stderr many people would probably complain about
these new messages appearing out of nowhere obstructing their script
executions, letting cronjobs fail and so on for no reason whatsoever
as apt did what it was asked for while explaining what it did so that
a user might know what happened if apt didn't do what the user wanted.


> These messages have not been shown at all until 2010, and then we enabled them for
> interactive users in 65beb5720f82845bf175e0cd80f070da21838827. Enabling that for
> non-interactive users can break stuff, so I'm not sure we want to change this.

The given apt-cache show example includes "No packages found" – that was
and still is in other commands an error reported as such, but hell
opened its gates than a naive me thought that reporting an error if show
finds no package would be a good thing…

sbuild is called out in cd7bbc479f8e2f277092a9557bb486ab664deba6, but
other tools like the scripts used to build Debian CDs (aka ISOs) are
allergic to changes as well, so the options were
- break the world, ignore the outcry (and be killed shortly after)
- revert everything by removing the messages again for everyone
- invent a new non-default flag nobody will ever use
- show them by default only in interactive use, guarded by existing -q

You may dislike my choice, but compared to the other options I can
manage a few dislikes in now 9 years of existence of that code and
countless people who are happy that they understood what went wrong
in their interactive use.


There are btw also other tools – some of which don't really have
a historic need – deploying tricks like this and there are others still
were I would be happy if they did as they would be easier to work with,
but that is the choice of the respective authors, not me, and certainly
not of a non-existent "industry standard".

Would apt be different if we ignored history more often? Certainly. It
would also be (for some value of) "better". But it would also be used by
fewer people as nobody likes it then others impose work on them – and
breaking interfaces is imposing work on those who use them.

None of us was around then the initial design included those interface
choices – that they managed to survive for 21 years is not proof that
they are good, but at least an indication that it isn't all bad.


As there is nothing we can really do about it and it hence can not be
considered an actionable bugreport I am closing as part wontfix part
not-a-bug(-we-could-fix).

Still, thanks for the report &
thanks for letting me walk down memory lane.

Best regards

David Kalnischkies

Attachment: signature.asc
Description: PGP signature


--- End Message ---
Reply to: