Hi!
On Fri, 2018-09-28 at 02:42:19 +1000, Craig Sanders wrote:
> Package: dpkg
> Version: 1.19.1
> 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".
> It also prevents dpkg's output from appearing in the scrollback buffer of
> terminal emulators because less (by default) switches to the alternate screen.
> This makes the output ugly and difficult to read on standard 80 column
> terminals because the output will now typically be longer than 80 columns
> wide. In fact, it's ugly and difficult to read on any terminal width
> less than the widest possible output line - it's no longer an easily read
> one-line-per-entry table, but a jumbled multiple-lines-per-entry mess.
Indeed, I realized about the new default not being more clear just a
bit before the upload, when I recalled I've got -S on my LESS
environment. :)
> 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.
> There were already several methods available to that user to get the output
> they preferred. They could have piped to cat (or 'less -S', or whatever)
> as they already knew how to do. or they could have set the COLUMNS variable
> before running dpkg, e.g.
>
> $ COLUMNS=132 dpkg -l pkg1 pkg2 pkg3 ...
> or, at least, modify it to use a DPKG_PAGER environment variable (and maybe
> DPKG_PAGER_OPTIONS for overriding the pager's default options).
>
> Better yet, make it configureable in /etc/dpkg/dpkg.cfg (I don't care what the
> default is as long as I can unset it or comment it out - without having to set
> it to cat)
>
> or add a -w or --wide option to dpkg. That would have been
> backwards-compatible with existing behaviour and expectations.
> or all of the above.
So, first, thanks for the constructive proposals! But I'd rather not
revert this change. I'm happy to implement anything sane people might
find useful to cope with such change. This includes the following
changes which I've started coding:
* DPKG_PAGER (equivalent to PAGER, so it will accept arguments).
* 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.
* 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).
* I could see perhaps a mode where the Description is omitted?
* 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.
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.
Thanks,
Guillem
