From jdl@chrome.onramp.net  Tue Aug 29 22:58:16 1995
Received: from mail.barrnet.net (mail.barrnet.net [131.119.246.7])
          by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id WAA11729
          for <FreeBSD-gnats-submit@freebsd.org>; Tue, 29 Aug 1995 22:58:06 -0700
Received: from chrome.onramp.net (chrome.onramp.net [199.1.166.202]) by mail.barrnet.net (8.6.10/MAIL-RELAY-LEN) with ESMTP id WAA25716 for <FreeBSD-gnats-submit@freebsd.org>; Tue, 29 Aug 1995 22:57:23 -0700
Received: (from jdl@localhost) by chrome.onramp.net (8.6.11/8.6.9) id AAA07802; Wed, 30 Aug 1995 00:54:36 -0500
Message-Id: <199508300554.AAA07802@chrome.onramp.net>
Date: Wed, 30 Aug 1995 00:54:36 -0500
From: jdl@chrome.onramp.net
Reply-To: jdl@chrome.onramp.net
To: FreeBSD-gnats-submit@freebsd.org
Subject: ls gives weird tabular form
X-Send-Pr-Version: 3.2

>Number:         715
>Category:       bin
>Synopsis:       ls gives weird tabular form
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    ache
>State:          closed
>Quarter:
>Keywords:
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Aug 29 23:00:01 PDT 1995
>Closed-Date:    Tue Aug 19 08:09:35 PDT 1997
>Last-Modified:  Tue Aug 19 08:25:37 PDT 1997
>Originator:     Jon Loeliger
>Release:        FreeBSD 2.0-BUILT-19950612 i386
>Organization:
Chromatic Research
>Environment:

Known to be in 2.0.5 7/26 SNAP and 2.2 -current

>Description:

The /bin/ls program gives weird tabular form depending on width of window.
On 2.0.5, a window with width of 111 gives nice output:

chrome 3374 % ls
COPYRIGHT       etc             mnt             stand           u01
OK              kernel          proc            sys             usr
bin             kernel.GENERIC  root            tmp             var
dev             lkm             sbin            u00

But a width of 112 gives odd behaviour:
chrome 3375 % ls
COPYRIGHT       dev             kernel.GENERIC  proc            stand                                          u00              var
OK              etc             lkm             root            sys                                            u01
bin             kernel          mnt             sbin            tmp                                            usr

Notice that at 111, it still only used the 80-columns of default.
On the 2.2 -current release, the odd happenings occur between 95/96.
Curiously, both cut off values are multiples of 8.  It smells of an
uninitialized variable in ls's formating somewhere?

>How-To-Repeat:

See Description.

>Fix:

Use a better window width.  Use ``ls -1'' :-)

>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->ache 
Responsible-Changed-By: scrappy 
Responsible-Changed-When: Sun May 26 22:51:13 PDT 1996 
Responsible-Changed-Why:  
last person mucking around in the code... 
State-Changed-From-To: open->closed 
State-Changed-By: jlemon 
State-Changed-When: Tue Aug 19 08:09:35 PDT 1997 
State-Changed-Why:  

This isn't a bug; ls calculates the requisite number of rows/cols needed to 
display the output, and then fills the slots in column order, not row order. 
With the given example, a column width of 112 results in 3 rows, while a 
width of 80 or 111 results in 4 rows; however, there just isn't enough data 
to fill a 6th column. 
>Unformatted:
