Bug: dir /2z produces incorrectly-formatted output

[lopower]

On a standard 80-column window, 'dir /2z' with TCC / TCC/LE 10.0.76 (i.e. the latest version) produces 82 columns of output. For example (with some character substitutions made because the editor is trying to parse them as control data):

[C:\WINDOWS\Fonts]dir /2z

.            [dir]      20/06/09  18:35   ..           [dir]      20/06/09  18:3
5
ARBLI___.TTF     65544  24/10/97  14:42   arial.ttf       367112  17/07/04  10:3
9
...

Widening the window to 82 columns avoids the problem. It looks like there are double spaces being inserted in many columns, if these were single-spaced (a) the output wouldn't overflow any more and (b) there'd be room to display a little more of the file name for longer filenames.

 

[jabelli]

I am getting 84 to 85, but I have my Windows short date set to yyyy-MM-dd.

 

[rconn]

> On a standard 80-column window, 'dir /2z' with TCC / TCC/LE 10.0.76
> (i.e. the latest version) produces 82 columns of output. For example
> (with some character substitutions made because the editor is trying to
> parse them as control data):

Two thoughts:

1) The /2 and /Z options are (long) obsolete, and only maintained for
compatibility with (very, very) old batch files or aliases.

2) There is no conceivable reason to limit your TCC window to 80 columns.

Rex Conn
JP Software

 

[lopower]

1) The /2 and /Z options are (long) obsolete, and only maintained for compatibility with (very, very) old batch files or aliases.

... and with pretty much every Unix shell in existence, for which multicolumn output is the default. Since TCC is about the closest you can get to a Unix shell under Windows, I would imagine there's a fair number of Unix users employing it for that purpose. The /Z isn't because I miss MSDOS but because I want to get the file size and date along with the name (a la 'ls -s'), and /Z is the best way of getting that, since going from 'dir' to 'dir /2' removes the size and date from the output. If there's another way of achieving the same result I'd be happy to use that.

2) There is no conceivable reason to limit your TCC window to 80 columns.

Hmm, this seems a bit like the joke about telling someone to stand on their head when they complain that the picture on their TV is upside-down :-). This does seem like a legitimate bug, since TCC isn't respecting the window size when it produces output.

(Besides, 80 columns has been the de factor standard width since the 1920s, and who am I to question teletypes and punched cards?).