2 replies to this topic

[David Lee]

I wanted to know the switches of imdisk, so I just typed (from CMD prompt)

C:\>imdisk

and the output was

Control program for the ImDisk Virtual Disk Driver.
For copyrights and credits, type imdisk --version

Syntax:
imdisk -a -t type -m mountpoint [-n] [-o opt1[,opt2 ...]] [-f|-F file]
       [-s size] [-b offset] [-v partition] [-S sectorsize] [-u unit]
       [-x sectors/track] [-y tracks/cylinder] [-p "format-parameters"] [-P]
...

so far so good. But when I redirected the output to a file:

C:\>imdisk 2>output.txt 

The output has many extra blank lines

Control program for the ImDisk Virtual Disk Driver.

For copyrights and credits, type imdisk --version


Syntax:

imdisk -a -t type -m mountpoint [-n] [-o opt1[,opt2 ...]] [-f|-F file]

       [-s size] [-b offset] [-v partition] [-S sectorsize] [-u unit]

       [-x sectors/track] [-y tracks/cylinder] [-p "format-parameters"] [-P]

...

when viewed from Command Prompt, Powershell shell or any text editors.

 

The output happened to be printed from function ImDiskSyntaxHelp(), in file cli/imdisk.c. It has a fputs() statement with '\r\n' all over the place instead of '\n'. Is it necessary? Even on Windows (AFAIK) on almost never needs to bother with a '\r' in front or '\n'. fprintf() and fputs() will smartly write 0x0d 0x0a for a single '\n' so '\r' is almost never needed.

 

Probably the same thing happens in other source files as well. Please review.

 

Thanks.

 

[Wonko the Sane]

It is an interesting (but "queer")  case. 

 

The output appears just fine in - say - Notepad, BUT when you copy and paste outside of Notepad, like here on the board, the additional linefeeds appear, and if you copy and paste what you just pasted on the board (let's say in a CODE window) the additional linefeed "stick".

 

The issue is that most Windows tools will automagically replace the sequence 0D0D0A (i.e. CR CR LF with *something else*).

 

If you paste it in word (and re-copy it) it will become 200D0A but it will be rendered (within word) as being "double newline".

Wordpad behaves differently, if you open the output with it it will replace 0D0D0A with 20 (effectively REMOVING newlines).

If you copy and paste it on the board and then re-copy it, 0D0D0A will be replaced by 0D0A0D0A.

 

TYPE and MORE have no issues displaying the file, though both MORE /E /P and MORE /E /S don't "see" the sequence as a "bad" one, so they don't correct the issue.

 

I guess that *somehow* we must stop calling this stuff "plain text"

 

Wonko

[Olof Lagerkvist]

Yes, you are right. I think this remains from some other console output library I used that called WriteFile directly and when I switched to C runtime functions I missed changing line breaks. I'll fix it soon!