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