Bug#834402: aptitude: search loses column format when redirected or piped

2016-11-18 Thread Yuri D'Elia 

Package: aptitude
Version: 0.8.3-1+b2
Followup-For: Bug #834402

I also consider this a regression. For instance, see this example:

aptitude -s search -F '%c%M %p' '~i' > status.txt

The width doesn't matter, I'm logging the output for archival. I actually
*want* infinite width.

But %M is now expanded to the empty string when missing, causing the output to
be mis-aligned. Fine, but consider the following tweak:

aptitude -s search -F '%c%1M %p' '~i' > status.txt

it *still* expands to empty, even though I'm requesting 1 column of output with
%1M in any condition.

This is broken.

-- Package-specific info:
Terminal: rxvt-unicode-256color
$DISPLAY is set.
which aptitude: /usr/bin/aptitude

aptitude version information:
aptitude 0.8.3
Compiler: g++ 6.2.0 20161103
Compiled against:
 apt version 5.0.0
 NCurses version 6.0
 libsigc++ version: 2.10.0
 Gtk+ support disabled.
 Qt support disabled.

Current library versions:
 NCurses version: ncurses 6.0.20160917
 cwidget version: 0.5.17
 Apt version: 5.0.0

aptitude linkage:
linux-vdso.so.1 (0x7ffcd5b67000)
libapt-pkg.so.5.0 => /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0 
(0x7fb2ddf5f000)
libncursesw.so.5 => /lib/x86_64-linux-gnu/libncursesw.so.5 
(0x7fb2ddd2f000)
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 
(0x7fb2ddb05000)
libsigc-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 
(0x7fb2dd8fe000)
libcwidget.so.3 => /usr/lib/x86_64-linux-gnu/libcwidget.so.3 
(0x7fb2dd601000)
libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 
(0x7fb2dd2f7000)
libboost_iostreams.so.1.62.0 => 
/usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.62.0 (0x7fb2dd0df000)
libboost_filesystem.so.1.62.0 => 
/usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.62.0 (0x7fb2dcec6000)
libboost_system.so.1.62.0 => 
/usr/lib/x86_64-linux-gnu/libboost_system.so.1.62.0 (0x7fb2dccc2000)
libxapian.so.30 => /usr/lib/x86_64-linux-gnu/libxapian.so.30 
(0x7fb2dc8b4000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7fb2dc697000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7fb2dc314000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7fb2dc01)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7fb2dbdf9000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fb2dba5b000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7fb2db857000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 
(0x7fb2db64)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7fb2db424000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 
(0x7fb2db214000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7fb2dafee000)
liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 
(0x7fb2daddc000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7fb2dabd4000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7fb2da9cd000)
/lib64/ld-linux-x86-64.so.2 (0x55d973091000)

-- System Information:
Debian Release: stretch/sid
 APT prefers unstable
 APT policy: (900, 'unstable'), (800, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.8.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages aptitude depends on:
ii  aptitude-common0.8.3-1
ii  libapt-pkg5.0  1.3.1
ii  libboost-filesystem1.62.0  1.62.0+dfsg-4
ii  libboost-iostreams1.62.0   1.62.0+dfsg-4
ii  libboost-system1.62.0  1.62.0+dfsg-4
ii  libc6  2.24-5
ii  libcwidget3v5  0.5.17-4+b1
ii  libgcc11:6.2.0-13
ii  libncursesw5   6.0+20160917-1
ii  libsigc++-2.0-0v5  2.10.0-1
ii  libsqlite3-0   3.15.1-1
ii  libstdc++6 6.2.0-13
ii  libtinfo5  6.0+20160917-1
ii  libxapian301.4.1-1

Versions of packages aptitude recommends:
ii  libparse-debianchangelog-perl  1.2.0-11
ii  sensible-utils 0.0.9

Versions of packages aptitude suggests:
ii  apt-xapian-index0.49
pn  aptitude-doc-en | aptitude-doc  
ii  debtags 2.1.2
pn  tasksel

Bug#834402: [Aptitude-devel] Bug#834402: aptitude: search loses column format when redirected or piped

2016-09-12 Thread Javier Cantero 
On Wed, Aug 17, 2016 at 10:46:59PM +0100, Manuel A. Fernandez Montecelo wrote:
 
> - somehow try to use the same width of the current terminal, with
>  possible truncation (would work fine in pipes for which the ultimate
>  output is the same terminal, but not if redirected and processed/seen
>  from another terminal/computer, unless the width is the same)

A way to get the width of the current terminal even when stdout was
redirected/piped is read it from stdin (fd 0) instead. With the
advantage that, unlike stdout, most of the times the standard input is
going to be connected directly to the terminal (I don't see actual cases
where somebody would want to redirect the standard input of aptitude to a
file/pipe, but maybe I'm wrong).

A simple proof of concept:

#include 
#include 
#include 

void check_term_size( int fd )
{
struct winsize ws;

if ( isatty(fd) )
{
printf( "tty at FD %d\n", fd );
if ( ioctl(fd, TIOCGWINSZ, ) != -1 )
{
printf( "ROWS=%d\n", ws.ws_row );
printf( "COLUMNS=%d\n", ws.ws_col );
}
}
}

int main( int argc, char* argv[] )
{
check_term_size( 1 ); /* stdout */
check_term_size( 0 ); /* stdin  */

return 0;
}


The downside is that the problem persists with redirections: they are
again dependent on the size of the terminal --meaning "aptitude search
 > kk" would be different depending on the current width of the
terminal where the command is executed. But that is the case the -w
option was created for, right?

-- 
   Saludos de Javier 




signature.asc
Description: PGP signature

Bug#834402: [Aptitude-devel] Bug#834402: aptitude: search loses column format when redirected or piped

2016-08-17 Thread Manuel A. Fernandez Montecelo 

Hi,

2016-08-16 19:18 Javier Cantero:

On Mon, Aug 15, 2016 at 11:25:40PM +0100, Manuel A. Fernandez Montecelo wrote:

The reasoning for the change was that with pipes/redirections the
concept of "terminal" and consequently "width" is lost.  If it's
redirected it's possibly/likely that it's because it's moved and
processed elsewhere (where the new terminal size will likely be
different), or that the further processing doesn't bother with terminal
columns or uses smarter methods like using '|' as field separators.


Counterexamples: any PAGER (more, less, ...), grep, sed, and virtually any
filter can interact with the terminal in a later stage of the pipeline.
In some cases like pagers there is *always* a terminal at the end.


That is the fundamental difference: the tool interacting with the
terminal is at the end, so the output is the terminal, so it can know
its dimensions.

If the tool is at the beginning, or at any point in the middle, the
output is a file or pipe (== a file for all purposes, from the tool's
POV), so it cannot know the dimensions.

For example, with a file with long lines such as apt's history.log:

 # less /var/log/apt/history.log > /tmp/test
 # md5sum /var/log/apt/history.log /tmp/test
 420a7acb08a4e58c9c6b97654aa1bb6a  /var/log/apt/history.log
 420a7acb08a4e58c9c6b97654aa1bb6a  /tmp/test

 # less --chop-long-lines /var/log/apt/history.log > /tmp/test
 # md5sum /var/log/apt/history.log /tmp/test
 420a7acb08a4e58c9c6b97654aa1bb6a  /var/log/apt/history.log
 420a7acb08a4e58c9c6b97654aa1bb6a  /tmp/test

 # less --chop-long-lines /var/log/apt/history.log | cat | md5sum
 420a7acb08a4e58c9c6b97654aa1bb6a  -


So they are exactly the same file.  "less" (at the start of the command
chain) doesn't insert newlines in the file or does any processing on the
input file with the "--chop-long-lines" option.  It treats the width of
the terminal as infinite.  This is what aptitude does now as well.


(Disclaimer: the tools or other tools that you mention perhaps still do
some trick to adapt to the terminal size even if the output is a
file/pipe, but well, my point is that the position and access to the
terminal is the fundamental difference between "cat | less" and
"aptitude | less"; and that "less" when not the last in the chain
behaves the same as the new behaviour of aptitude).



In other words, trying to columnize the output when the width is unknown
(pipes or redirections) is a bit hacky and doesn't make much sense to
me, and forcing it to be 80 for a lack of better default is not always a
good solution as it might have been back in ~2000 (I think).


I agree that forcing to be 80 is hacky. But there is a better solution:
if the output isn't to a terminal (and -w is not passed), write the
entire output without truncating to any width size and let the next
process in the pipeline deal with it. If it's the last process before
going to terminal, I'm sure that program will have code to properly
adapt its output to the actual terminal size. In one sentence: delegate
the job to the process dealing with the terminal.


Actually, aptitude /now/ works as you say and for the same reasons that
you say, so we could be in violent agreement.  Only that I suspect that
we are not, because that's why you submitted the original bug report
after all... :)

So as you say, what aptitude does is that "if the output isn't to a
terminal (and -w is not passed), write the entire output without
truncating to any width size and let the next process in the pipeline
deal with it".  It does not truncate the output now when it's at the
start of a chain of commands.

Only that to columnize the output, it has to have some reference to the
width that it's going to "render" the output to, because most fields can
shrink and expand -- they are not of a fixed size.  And knowing the
width is exactly what it's lacking to columnize the output when
piping/redirecting.  If aptitude considers width as infinite, same as
"less", all rows are of infinite width (infinite being 65536 in the
implementation).

So the new behaviour is that, instead of columnizing to 80 and
truncating, it doesn't truncate (but doesn't columnize).


If it doesn't truncate and also doesn't have a width and doesn't want to
use the infinite, the only solution for columnizing would be to do two
passes: one collecting the maximum size of the columns for all packages
that match the search ("search" and other commands that use the same
columnizer code), and another pass to actually write the text and fill
with blanks until the max width of the column is filled in.

In this case, if using "aptitude search ${pattern} | less", searches
would have different widths -- the output would depend on the max length
of the fields for the packages that match.  Like this:

 |-|
 i A aptitude an awesome package manager that everyone loves
 |-|

Bug#834402: [Aptitude-devel] Bug#834402: aptitude: search loses column format when redirected or piped

2016-08-16 Thread Javier Cantero 
On Mon, Aug 15, 2016 at 11:25:40PM +0100, Manuel A. Fernandez Montecelo wrote:
> The reasoning for the change was that with pipes/redirections the
> concept of "terminal" and consequently "width" is lost.  If it's
> redirected it's possibly/likely that it's because it's moved and
> processed elsewhere (where the new terminal size will likely be
> different), or that the further processing doesn't bother with terminal
> columns or uses smarter methods like using '|' as field separators.

Counterexamples: any PAGER (more, less, ...), grep, sed, and virtually any
filter can interact with the terminal in a later stage of the pipeline.
In some cases like pagers there is *always* a terminal at the end.

> In other words, trying to columnize the output when the width is unknown
> (pipes or redirections) is a bit hacky and doesn't make much sense to
> me, and forcing it to be 80 for a lack of better default is not always a
> good solution as it might have been back in ~2000 (I think).

I agree that forcing to be 80 is hacky. But there is a better solution:
if the output isn't to a terminal (and -w is not passed), write the
entire output without truncating to any width size and let the next
process in the pipeline deal with it. If it's the last process before
going to terminal, I'm sure that program will have code to properly
adapt its output to the actual terminal size. In one sentence: delegate
the job to the process dealing with the terminal.


-- 
   Saludos de Javier 




signature.asc
Description: PGP signature

Bug#834402: [Aptitude-devel] Bug#834402: aptitude: search loses column format when redirected or piped

2016-08-15 Thread Manuel A. Fernandez Montecelo 

Hi,

2016-08-15 20:54 Axel Beckert:

Hi Manuel,

Manuel A. Fernandez Montecelo wrote:

In the past it was just hardcoded to "80 columns", so your example when
doing it with and without pipe/redirection will have looked different as
well -- unless the terminal that you are using is 80-column wide, of
course.  (See attachment, the description is truncated).


Either your examples show something different or not the problem:


$ aptitude search '~i~n^aptitude'
i   aptitude
  - terminal-based package manager
i   aptitude-common 
  - architecture independent files for the aptitude package manager

$ aptitude search '~i~n^aptitude' | cat
i   aptitude- terminal-based package manager
i   aptitude-common - architecture independent files for the apt


This definitely looks different here and IIRC also for the original
submitter:
[...]
Manuel: I really wonder why your examples looked different than mine
wrt. to aligned columns. Maybe some different options being set via
configuration files?


Sorry that I was not very explicit... with "In the past" I meant the
version in stable/Jessie (or for that matter, any older than that), and
I was only saying that the output would have looked different in one way
or another.  (There were complaints in previous bug reports about
different aspects of this issue).

For example, if the default fields are used, the description will almost
always be truncated, sometimes in a slightly confusing ways as for
example in the case of aptitude-common above -- where it's not visually
obvious by the context that it was truncated, and one might thing that
aptitude just fails to process the short description incorrectly.

That is, the output when piping and redirecting was always different to
the "direct-to-terminal" one unless the terminal width happened to be
80.


To get always columns with these commands, no matter what, one can
define it explicitly, either with "-w" or with
Aptitude::CmdLine::Package-Display-Width (in the latter case, -w
overrides the config variable).  Of course, if one hardcodes
Aptitude::CmdLine::Package-Display-Width to e.g. 80 to have the same
behaviour as before, then it'll will always use 80 when outputting
directly to the terminal, unless overridden.

Aptitude::CmdLine::Package-Display-Format can also be used to define
another format, perhaps removing uninteresting fields (description?) and
setting explicit widths for the fields.

Another work around for the new behaviour is e.g.:

 $ alias aptitude-search="aptitude -w $COLUMNS search"


The reasoning for the change was that with pipes/redirections the
concept of "terminal" and consequently "width" is lost.  If it's
redirected it's possibly/likely that it's because it's moved and
processed elsewhere (where the new terminal size will likely be
different), or that the further processing doesn't bother with terminal
columns or uses smarter methods like using '|' as field separators.

In other words, trying to columnize the output when the width is unknown
(pipes or redirections) is a bit hacky and doesn't make much sense to
me, and forcing it to be 80 for a lack of better default is not always a
good solution as it might have been back in ~2000 (I think).


Cheers.
--
Manuel A. Fernandez Montecelo

Bug#834402: [Aptitude-devel] Bug#834402: aptitude: search loses column format when redirected or piped

2016-08-15 Thread Axel Beckert 
Hi Manuel,

Manuel A. Fernandez Montecelo wrote:
> In the past it was just hardcoded to "80 columns", so your example when
> doing it with and without pipe/redirection will have looked different as
> well -- unless the terminal that you are using is 80-column wide, of
> course.  (See attachment, the description is truncated).

Either your examples show something different or not the problem:

> $ aptitude search '~i~n^aptitude'
> i   aptitude  
> - terminal-based package manager
> i   aptitude-common   
> - architecture independent files for the aptitude package manager
> 
> $ aptitude search '~i~n^aptitude' | cat
> i   aptitude- terminal-based package manager
> i   aptitude-common - architecture independent files for the 
> apt

This definitely looks different here and IIRC also for the original
submitter:

~ → aptitude search '~i~n^aptitude' | cat
i A aptitude - terminal-based package manager
i A aptitude-common - architecture independent files for the aptitude package 
manager
i A aptitude-doc-en - English manual for aptitude, a terminal-based package 
manager

In the above example the descriptions are no more aligned while they
are in your examples with the very same command (and for me with
0.6.11-1 on Jessie, too).

It gets even worse if automatically and manually installed packages
are mixed in the output:

~ → aptitude search \~i | head
i A 0ad - Real-time strategy game of ancient warfare
i A 0ad-data - Real-time strategy game of ancient warfare (data files)
i A 0ad-data-common - Real-time strategy game of ancient warfare (common data 
files)
i  0x - Open Free Fiasco Firmware Flasher
i A 2048-qt - mathematics based puzzle game
i A 2ping - Ping utility to determine directional packet loss
i A 9menu - Creates X menus from the shell
i  abduco - terminal session manager
i A abe-archive-tools - Packages needed to read exotic archive formats
i A abe-commandline - Metapackage of commandline tools Axel usually installs

Now even the package names are no more aligned.

IMHO this misalignment is what this bug report is about.

And yes, if you add an arbitrary value to -w, the column-based,
aligned layout comes back:

~ → aptitude search -w 80 '~i~n^aptitude' | cat
i A aptitude- terminal-based package manager
i A aptitude-common - architecture independent files for the apt
i A aptitude-doc-en - English manual for aptitude, a terminal-ba
~ → aptitude -w 80 search \~i | head
i A 0ad - Real-time strategy game of ancient warfare
i A 0ad-data- Real-time strategy game of ancient warfare
i A 0ad-data-common - Real-time strategy game of ancient warfare
i   0x  - Open Free Fiasco Firmware Flasher 
i A 2048-qt - mathematics based puzzle game 
i A 2ping   - Ping utility to determine directional pack
i A 9menu   - Creates X menus from the shell
i   abduco  - terminal session manager  
i A abe-archive-tools   - Packages needed to read exotic archive for
i A abe-commandline - Metapackage of commandline tools Axel usua

Manuel: I really wonder why your examples looked different than mine
wrt. to aligned columns. Maybe some different options being set via
configuration files?

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#834402: aptitude: search loses column format when redirected or piped

2016-08-15 Thread Manuel A. Fernandez Montecelo 

Hi,

2016-08-15 11:59 Axel Beckert:

Control: tag -1 + confirmed

Hi Javier,

Javier Cantero wrote:

Compare this:

$  aptitude search "~i aptitude"
i   aptitude0.8.3-1 
   - gestor de paquetes basado en terminal
i A aptitude-common 0.8.3-1 
   - architecture independent files for the aptitude package manager

with the same output piped through `less`:

$  aptitude search "~i aptitude" | less
i  aptitude 0.8.3-1 - gestor de paquetes basado en terminal
i A aptitude-common 0.8.3-1 - architecture independent files for the 
aptitude package manager

The same happens if the output is redirected to a file:

$  aptitude search "~i aptitude" > kk.txt
$  cat kk.txt
i  aptitude 0.8.3-1 - gestor de paquetes basado en terminal
i A aptitude-common 0.8.3-1 - architecture independent files for the 
aptitude package manager


Indeed. This looks like a regression from the version in Debian Jessie.


I've already read the discussion in #815690. but the thing is: piping to
more/less is a very common usage of aptitude search (since the lists of
packages tend to be very long), not just a special case for automatic
processing of the output. It's really annoying to have to remember to add
an arbitrary[*] width using `-w` in every `aptitude search ... | less`,
especially when it's a significant deviation from previous behaviour.


I agree here, but I'm still not sure what's the best way to handle
this case.


It's not a regression, or at least not an unintended one.  It was
directed to fix the problems described in #445206 and #496728.

The width given with -w is not arbitrary, it's the one that one wants
the lines to have (at least for me, it works differently if one sets 80,
100 or 160).  -w $COLUMNS should work fine if looking it directly in a
terminal, or if you want the pipe/redirection to have exactly the same
width as your current terminal.

In the past it was just hardcoded to "80 columns", so your example when
doing it with and without pipe/redirection will have looked different as
well -- unless the terminal that you are using is 80-column wide, of
course.  (See attachment, the description is truncated).


Cheers.
--
Manuel A. Fernandez Montecelo 
$ aptitude search '~i~n^aptitude'
i   aptitude
  - terminal-based package manager
i   aptitude-common 
  - architecture independent files for the aptitude package manager

$ aptitude search '~i~n^aptitude' | cat
i   aptitude- terminal-based package manager
i   aptitude-common - architecture independent files for the apt

Bug#834402: [Aptitude-devel] Bug#834402: aptitude: search loses column format when redirected or piped

2016-08-15 Thread Axel Beckert 
Control: tag -1 + confirmed

Hi Javier,

Javier Cantero wrote:
> Compare this:
> 
>   $  aptitude search "~i aptitude"
>   i   aptitude0.8.3-1 
>- gestor de paquetes basado en terminal
>   i A aptitude-common 0.8.3-1 
>- architecture independent files for the aptitude package manager
> 
> with the same output piped through `less`:
> 
>   $  aptitude search "~i aptitude" | less
>   i  aptitude 0.8.3-1 - gestor de paquetes basado en terminal
>   i A aptitude-common 0.8.3-1 - architecture independent files for the 
> aptitude package manager
> 
> The same happens if the output is redirected to a file:
> 
>   $  aptitude search "~i aptitude" > kk.txt
>   $  cat kk.txt 
>   i  aptitude 0.8.3-1 - gestor de paquetes basado en terminal
>   i A aptitude-common 0.8.3-1 - architecture independent files for the 
> aptitude package manager

Indeed. This looks like a regression from the version in Debian Jessie.

> I've already read the discussion in #815690. but the thing is: piping to
> more/less is a very common usage of aptitude search (since the lists of
> packages tend to be very long), not just a special case for automatic
> processing of the output. It's really annoying to have to remember to add
> an arbitrary[*] width using `-w` in every `aptitude search ... | less`,
> especially when it's a significant deviation from previous behaviour.

I agree here, but I'm still not sure what's the best way to handle
this case.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#834402: aptitude: search loses column format when redirected or piped

2016-08-15 Thread Javier Cantero 
Package: aptitude
Version: 0.8.3-1
Severity: normal

Dear Maintainer,

Compare this:

$  aptitude search "~i aptitude"
i   aptitude0.8.3-1 
   - gestor de paquetes basado en terminal
i A aptitude-common 0.8.3-1 
   - architecture independent files for the aptitude package manager

with the same output piped through `less`:

$  aptitude search "~i aptitude" | less
i  aptitude 0.8.3-1 - gestor de paquetes basado en terminal
i A aptitude-common 0.8.3-1 - architecture independent files for the 
aptitude package manager

The same happens if the output is redirected to a file:

$  aptitude search "~i aptitude" > kk.txt
$  cat kk.txt 
i  aptitude 0.8.3-1 - gestor de paquetes basado en terminal
i A aptitude-common 0.8.3-1 - architecture independent files for the 
aptitude package manager

I've already read the discussion in #815690. but the thing is: piping to
more/less is a very common usage of aptitude search (since the lists of
packages tend to be very long), not just a special case for automatic
processing of the output. It's really annoying to have to remember to add
an arbitrary[*] width using `-w` in every `aptitude search ... | less`,
especially when it's a significant deviation from previous behaviour.


[*] arbitrary because usually it doesn't matter the actual width


-- Package-specific info:
Terminal: xterm
$DISPLAY is set.
which aptitude: /usr/bin/aptitude

aptitude version information:
aptitude 0.8.3
Compiler: g++ 6.1.1 20160802
Compiled against:
  apt version 5.0.0
  NCurses version 6.0
  libsigc++ version: 2.8.0
  Gtk+ support disabled.
  Qt support disabled.

Current library versions:
  NCurses version: ncurses 6.0.20160625
  cwidget version: 0.5.17
  Apt version: 5.0.0

aptitude linkage:
linux-vdso.so.1 (0x7fffd27cc000)
libapt-pkg.so.5.0 => /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0 
(0x7faf90684000)
libncursesw.so.5 => /lib/x86_64-linux-gnu/libncursesw.so.5 
(0x7faf90454000)
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 
(0x7faf90229000)
libsigc-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 
(0x7faf90022000)
libcwidget.so.3 => /usr/lib/x86_64-linux-gnu/libcwidget.so.3 
(0x7faf8fd25000)
libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 
(0x7faf8fa2)
libboost_iostreams.so.1.61.0 => 
/usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.61.0 (0x7faf8f808000)
libboost_filesystem.so.1.61.0 => 
/usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.61.0 (0x7faf8f5ef000)
libboost_system.so.1.61.0 => 
/usr/lib/x86_64-linux-gnu/libboost_system.so.1.61.0 (0x7faf8f3ea000)
libxapian.so.22 => /usr/lib/x86_64-linux-gnu/libxapian.so.22 
(0x7faf8efe6000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7faf8edc9000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7faf8ea47000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7faf8e742000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7faf8e52c000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7faf8e18a000)
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x7faf8df87000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7faf8dd83000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 
(0x7faf8db6b000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7faf8d95)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 
(0x7faf8d74)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7faf8d51c000)
liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 
(0x7faf8d30a000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7faf8d101000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7faf8cefc000)
/lib64/ld-linux-x86-64.so.2 (0x5571f0e7b000)

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (600, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.6.6-amd64 (SMP w/4 CPU cores)
Locale: LANG=es_ES.utf8, LC_CTYPE=es_ES.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages aptitude depends on:
ii  aptitude-common0.8.3-1
ii  libapt-pkg5.0  1.3~pre3
ii  libboost-filesystem1.61.0  1.61.0+dfsg-2.1
ii  libboost-iostreams1.61.0   1.61.0+dfsg-2.1
ii  libboost-system1.61.0  1.61.0+dfsg-2.1
ii  libc6  2.23-4
ii  libcwidget3v5  0.5.17-4+b1
ii  libgcc11:6.1.1-11
ii  libncursesw5   6.0+20160625-1
ii  libsigc++-2.0-0v5  2.8.0-2
ii  libsqlite3-0   3.13.0-1
ii  libstdc++6