<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 25, 2016 at 5:43 AM, John Lenton <span dir="ltr"><<a href="mailto:john.lenton@canonical.com" target="_blank">john.lenton@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">With your suggestion for "snap find" output, even with the paltry<br>
packages we have today, you already have just three characters left<br>
before the 80th column for summary, and a third of that width is used<br>
up for "version". That seems wrong to me, and it's only going to get<br>
worse as "Notes" gets used.<br></blockquote><div><br></div><div>The length of those fields does not depend on the number of packages we have. We can have just a few, and be close to the maximum expected width. And unfiltered find is likely to get very busy indeed, because you'll always be hitting the worst possible width available for all fields. Eventually we should likely prevent that command from running altogether. </div><div><br></div><div>Looking at my 16.04 installation for more relevant data, the max length for versions is 52, but the average is 12 and the median is 7. The output of unfiltered dpkg -l starts the summary at column 129, despite displaying only the name, version, arch, and summary.</div><div><br></div><div>I don't think we can win if the goal is having meaningful output for everything under 80 columns.</div><div><br></div><div><br></div></div><div class="gmail_signature">gustavo @ <a href="http://niemeyer.net" target="_blank">http://niemeyer.net</a></div>
</div></div>