On Tue, Oct 02, 2018 at 04:48:30AM +0200, Guillem Jover wrote: > > This is exactly the opposite of how unix programs should behave - stdout > > goes to a tty unless redirected. If a user **wants** to view the output of > > a program in a pager, then they can pipe it to less or whatever themselves. > > That's standard usage of the unix shell. Hard-coding a program to always > > use > > a pager is wrong. > > I also don't think historic Unix commands (CLI, not TUI) traditionally > truncate (in contrast to perhaps just adapting their output to it) to fit > the screen, TBH? And I had to agree this seems rather perplexing and can > catch people off-guard with the "data-loss".
yeah, that's a bit of a grey area. OTOH dpkg has a 25+ year history of doing exactly that, so changing the behavior without providing any way of getting the old behaviour back is...disconcerting at the very least. Imagine how popular it would be if, say, grep's behaviour was suddenly changed to automatically pipe its output to less. as a convenience. for your own good. > > Looking through the changelog, this seems to be an attempt to "solve" > > #898603 which was a non-problem that didn't need fixing. > > I don't agree with this, I think the previous behavior was not a really good > default. I was expecting such change would make some people unhappy, and had > already some of the changes you propose in mind to help with that (but not > all!), but wanted to get 1.19.1 out of the way and not block on these. The old behaviour was almost right. What it got wrong was not prioritising package name and version fields over description. It should have only truncated the description field (if at all possible within the COLUMNS width). The point of dpkg -l is to give you a quick, easily readable table of packages(*), and sacrificing precision for readability is the right thing to do there. Especially when it's easy to redirect to a file or pipe to a pager or cat or grep/sed/awk/whatever (or just set COLUMNS) to get un-truncated output. Now, I've have had choice taken away from me. I used to have the choice of viewing the output in a pager or not. Of viewing the full, untruncated details OR a condensed view that fit my terminal width, and even manually setting COLUMNS to limit the width to whatever I currently need. Now I don't have any of those choices. My choices now are "view in a pager" or "ugly, unreadable multi-line mess". (*) and for answering questions like "Do I have package X installed on this machine? and if so, what version?". Getting dumped into a pager when I'm expecting either a few lines of output on my tty or an error message is jarring and disrupts what I'm trying to do on the command line. > * DPKG_PAGER (equivalent to PAGER, so it will accept arguments). If you're still going to have it pipe to less by default, then there should be some way of using this var to tell dpkg not to use a pager. perhaps "DPKG_PAGER=none" (which assumes that there isn't a program called "none" in the PATH) or "DPKG_PAGER=-". > * Set LESS (if unset) to something along the lines of -FRSXMQ, which > sould fix the clear-screen-problem, the ugly-output, and > blocking-on-pager-when-unnecessary. I already have LESS set to what I want (and mostly the alt screen IS exactly what I want when viewing files or man pages or whatever - because I don't want such things flooding my scrollback buffer). I don't want to have to change that just to cater to dpkg or other programs that pipe to less when I don't want them to. In other words, I don't want to have to make my normal usage of less significantly more annoying just to make dpkg's new behaviour slightly less annoying. > * New --no-pager option (that can be set in the config file, for > dpkg, although dpkq-query does not currently honor any config, > but I might need to implement something for the path mapping > options anyway in the future). A --no-pager option would be an OK compromise. Especially if I could set it as the default, and it didn't interfere with me manually piping or redirecting the output. I suppose at the worst, I could alias it. or write a /usr/local/sbin/dpkg wrapper script with 'dpkg --no-pager "$@"' > * I could see perhaps a mode where the Description is omitted? having some description in the output is useful. better to truncate desc to keep output line length < COLUMNS. > * If you still want the truncating behavior, I could introduce it > back under a new option such as --width=fit-to-screen vs =auto vs > =<COLUMNS> or similar. That would work too. In fact, it's probably the best option. It gives the old behaviour for those who want it (and using the COLUMNS var **was** useful to, e.g., format the output for email). > On Fri, 2018-09-28 at 11:40:38 +0000, Holger Levsen wrote: > > also, running eg 'dpkg -l dpkg' and then ending up in less is confusing > > and breaking >20y old habbits, and then I press 'q' and get exit code 1. > > Ah! That's actually a bug, the process dies from a SIGPIPE, I'll fix > that. > > On the backwards incompatible change, well, this part is human > interaction only, and while that might perhaps be one of the trickest > to get used to, I considered the pros and cons, and that several other > tools that produce lots of output (such as git) do that by default, > which seems rather convenient. I find it annoying when git does that too (it's almost as annoying as programs that print --help output to stderr instead of stdout). I know what pipes are and if I want the output in a pager, I'll pipe it there myself. Fortunately, git has its own GIT_PAGER env var so I don't have to change my default settings just to cater to one program. That's why I suggested the same for dpkg. BTW, this change is particularly annoying when dpkg has no output (e.g. from 'dpkg -l non-existant-pkg') and I end up in less displaying nothing, with the "dpkg-query: no packages found matching non-existant-pkg" message on stderr hidden behind less. The big problem is the surprising change in behaviour and the lack of consistency. Command line tools should behave consistently, and the standard is that non-error output goes to stdout and errors go to stderr - users shouldn't have to remember dozens or hundreds of "special case" exceptions like "program X does this weird thing" and "program Y does that weird thing". Predictable, consistent behaviour is one of the things that make using the shell pleasant and efficient. craig PS: Fortunately, I still had dpkg 1.19.0.5+b1 installed in one of my VMs, so I used dpkg-repack to repackage it and have installed that on all my systems, and then used "apt-mark hold" to prevent it from being auto-upgraded. I'll leave it like that until this problem is fixed. -- craig sanders <c...@taz.net.au>
