ls-F output wraps.

Christos Zoulas christos at zoulas.com
Tue Aug 12 11:16:28 EEST 2008


On Aug 12,  8:08am, R.E.Wolff at BitWizard.nl (Rogier Wolff) wrote:
-- Subject: Re: ls-F output wraps.

| 
| Hi,
| 
| I sent a bugreport together with a fix, but didn't hear from it
| anymore, so I'm suspecting that the moderator is dropping mail from
| non-subscribers in a bulk mode, because most of it is spam anyway.
| The promised "rejection" or "accpetance" notice never came. 
| 
| 
| Here is the report: 
| 
| 
| Since a while, apparently (especially when there are short names
| involved) ls-F will calculate the total required space for <n> colums
| too small. This causes the columns that are supposed to fit on one
| line to wrap. This is ugly.
| 
| For my testrun my window was 80 wide. The cut-paste inserted the
| newlines you find in this Email message, which is in this case
| exactly what I want. (to show you the problem.)
| 
| I've been annoyed at this problem for a while now, but hadn't
| gotten around to figuring out what was wrong. Turns out it is
| not "gnu coreutils" that is wrong, but the tcsh-builtin.
| 
| zebigbos:..../collinks> /bin/ls -F
| 0/    13c/  188/  1dc/  22c/  28/   2cc/  31c/  368/  3ac/  3f4/  7c/  c4/
| 10/   14/   18c/  1e0/  230/  280/  2d0/  31e/  36c/  3b0/  3f8/  8/   c8/
| 100/  140/  190/  1e4/  234/  284/  2d2/  320/  370/  3b2/  3fc/  80/  cc/
| [...]
| zebigbos:..../collinks> ls-F
| 0/    132/  170/  1b0/  1f8/  238/  27c/  2c/   30/   34/   38/   3b2/  3ec/  6c
| /   a8/   e6/
| 10/   134/  174/  1b4/  1fc/  23c/  28/   2c0/  300/  340/  380/  3b4/  3f0/  70
| /   ac/   e8/
| 100/  138/  178/  1b8/  1fe/  24/   280/  2c4/  304/  342/  384/  3b8/  3f4/  72
| /   b0/   ec/
| [...]
| zebigbos:..../collinks>
| 
| 
| So I fixed it.
| 
| I thought the problem might be related to the fact that I disabled the
| color listings. However, I cannot reproduce turning the colors back
| on. Apparently I've got it convinced that I don't like colors.
| 
| Anyway, without the below patch,
| 
|         w = (unsigned int) NLSStringWidth(items[i]) + wx;
| 
| on line 2112 of (my version of) tw.parse.c counts one character less
| than actually output. So it counts "3" chars for my example
| case. Because "maxwidth" was correctly calculated to be 5 (in this
| case 4+1, and not the expected 3+2), the loop on lines 2113 and 2114
| outputs two extra spaces, where only one is expected/required.....
| 
| I now see that /bin/ls outputs TWO spaces between each of the columns,
| while as far as I can see the tcsh code was intended to output ONE
| space between columns. So that's what I made it do, but it was also
| intended to mimic /bin/ls behaviour....
| 
|         Roger.
| 
| 
| --- rew/tcsh-6.14.00/tw.parse.c 2005-03-03 17:40:53.000000000 +0100
| +++ tcsh-6.14.00/tw.parse.c     2008-08-08 17:13:56.000000000 +0200
| @@ -2088,6 +2088,7 @@
|                     Char f = items[i][w - 1];
|                     items[i][w - 1] = 0;
|                     print_with_color(items[i], w - 1, f);
| +                   items[i][w - 1] = f;
|                 }
|                 else {
|                     /* Print filename followed by '/' or '*' or ' ' */
| 
| 

Thanks, but this bug has been fixed a long time ago:

3.106        (kim      11-Apr-05):                  items[i][w - 1] = f;

and the fix is still present in the current version of tcsh (6.15).

Best,

christos



More information about the Tcsh-Bugs mailing list