I think there is a bug here, but can you please try it a bit? The name of this program is "test.d", so it loads its souce code:

import std.file: readText;
import std.stdio: write;
void main() {
    string s = readText("test.d");
    write(s);
}


On windows the output is:
import std.file: readText;

import std.stdio: write;

void main() {

    string s = readText("test.d");

    write(s);

}


So it shows extra newlines (on Windows newlines are two chars).

On Windows a similar Python program doesn't show the doubled newlines:
s = open("test.d").read()
print s

Bye,
bearophile

I'm getting normal newlines here (XP):

C:\output>test.exe
import std.file: readText;
import std.stdio: write;
void main() {
    string s = readText("test.d");
    write(s);
}

The text used CR+LF newlines. I also tried them using LF newlines, which worked fine. But I've then tried with CR and that gives out weird output like so:

}   write(s);= readText("test.d");


bearophile Wrote:

> I think there is a bug here, but can you please try it a bit? The name of this program is "test.d", so it loads its souce code:
> 
> import std.file: readText;
> import std.stdio: write;
> void main() {
>     string s = readText("test.d");
>     write(s);
> }
> 
> 
> On windows the output is:
> import std.file: readText;
> 
> import std.stdio: write;
> 
> void main() {
> 
>     string s = readText("test.d");
> 
>     write(s);
> 
> }
> 
> 
> So it shows extra newlines (on Windows newlines are two chars).
> 
> On Windows a similar Python program doesn't show the doubled newlines:
> s = open("test.d").read()
> print s
> 
> Bye,
> bearophile

Oh and I'm getting the same issue in Python when using CR only. I don't know why I have the CR option in the text editor if it doesn't work properly. I guess CR is used on the Macs maybe..?

Andrej Mitrovic Wrote:

> I'm getting normal newlines here (XP):
> 
> C:\output>test.exe
> import std.file: readText;
> import std.stdio: write;
> void main() {
>     string s = readText("test.d");
>     write(s);
> }
> 
> The text used CR+LF newlines. I also tried them using LF newlines, which worked fine. But I've then tried with CR and that gives out weird output like so:
> 
> }   write(s);= readText("test.d");
> 
> 
> bearophile Wrote:
> 
> > I think there is a bug here, but can you please try it a bit? The name of this program is "test.d", so it loads its souce code:
> > 
> > import std.file: readText;
> > import std.stdio: write;
> > void main() {
> >     string s = readText("test.d");
> >     write(s);
> > }
> > 
> > 
> > On windows the output is:
> > import std.file: readText;
> > 
> > import std.stdio: write;
> > 
> > void main() {
> > 
> >     string s = readText("test.d");
> > 
> >     write(s);
> > 
> > }
> > 
> > 
> > So it shows extra newlines (on Windows newlines are two chars).
> > 
> > On Windows a similar Python program doesn't show the doubled newlines:
> > s = open("test.d").read()
> > print s
> > 
> > Bye,
> > bearophile
> 

On Saturday 31 July 2010 20:10:05 Andrej Mitrovic wrote:
> Oh and I'm getting the same issue in Python when using CR only. I don't know why I have the CR option in the text editor if it doesn't work properly. I guess CR is used on the Macs maybe..?

Prior to Macs becoming Unix based, they used '\r' for the end-of-line character. Once they became Unix based, they did what Unix does and used '\n'. So, at this point, you really only have to worry about '\n' vs '\r\n' with Windows being the only odd man out.

The funny thing is that _technically_ speaking, Windows is right: a newline drops down a line, and carriage return goes to the beginning of a line, so both are necessary. But since we don't use typewriters anymore or use consoles in that way, combing them into one character like C did is better, and that's what most everything does. So, while Wnidows is arguably more correct, it causes problems and is arguably inferior.

- Jonathan M Davis

Andrej Mitrovic:

> I'm getting normal newlines here (XP):

Thank you for your test. Then maybe it's a problem that comes out on Windows Vista only, I don't know.

---------------------

Jonathan M Davis:

> So, while Wnidows is arguably more correct, it causes problems and is arguably inferior.

The point is that probably there is a newline-related bug somewhere in Phobos and I'd like to find it.

Bye,
bearophile

On 01/08/2010 13:12, bearophile wrote:
> Andrej Mitrovic:
>
> The point is that probably there is a newline-related bug somewhere in Phobos and I'd like to find it.
>
> Bye,
> bearophile

Yeah there is.

I get doubled new lines as well when passing a handle opened with fopen to a CFile thingy.

On 01/08/2010 18:22, div0 wrote:
> On 01/08/2010 13:12, bearophile wrote:
>> Andrej Mitrovic:
>>
>> The point is that probably there is a newline-related bug somewhere in
>> Phobos and I'd like to find it.
>>
>> Bye,
>> bearophile
>
> Yeah there is.
>
> I get doubled new lines as well when passing a handle opened with fopen
> to a CFile thingy.

That's on XP btw

On Sunday 01 August 2010 05:12:04 bearophile wrote:
> Jonathan M Davis:
> > So, while Wnidows is arguably more correct, it causes problems and is arguably inferior.
> 
> The point is that probably there is a newline-related bug somewhere in Phobos and I'd like to find it.

Oh, I don't disagree. I'm just pointing out the situation with the various end- of-line characters on the various OSes. It sounds like the two character solution of Windows might be messing things up somewhere, but I was just pointing out the character situation. However, the error does indeed need to be found and fiixed.

- Jonathan M Davis

On Sat, 31 Jul 2010 23:10:05 -0400, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:

> Oh and I'm getting the same issue in Python when using CR only. I don't know why I have the CR option in the text editor if it doesn't work properly. I guess CR is used on the Macs maybe..?
>
> Andrej Mitrovic Wrote:
>
>> I'm getting normal newlines here (XP):
>>
>> C:\output>test.exe
>> import std.file: readText;
>> import std.stdio: write;
>> void main() {
>>     string s = readText("test.d");
>>     write(s);
>> }
>>
>> The text used CR+LF newlines. I also tried them using LF newlines, which worked fine. But I've then tried with CR and that gives out weird output like so:
>>
>> }   write(s);= readText("test.d");

CR means carriage return.  This is for old-style line printers.  When you sent a CR, it means, literally, move the carriage back to the front of the line.  When you sent a LF (line feed), it means, feed the paper another line.

If you printed a file to such a printer with just line feeds, you would see:

import std.file: readText;
                          import std.stdio: write;
                                                  void main() {
...


If you printed the file with just CRs, you would see all the lines super-imposed over eachother, because the paper is never moved, just the carriage is returned.

This is the effect you are seeing, each line is super-imposed over the other.  However, on a terminal, you don't see the residual letters from previously printed lines, they are completely overwritten.

Essentially, if you put in a sleep between printing each line, what you'd see is this:

import std.file: readText;

.. pause ..

import std.stdio: write;t;

.. pause ..

void main() {dio: write;t;

....

Hope this helps ;)

-Steve

On Sat, 31 Jul 2010 21:15:21 -0400, bearophile <bearophileHUGS@lycos.com> wrote:

> I think there is a bug here, but can you please try it a bit?
> The name of this program is "test.d", so it loads its souce code:
>
> import std.file: readText;
> import std.stdio: write;
> void main() {
>     string s = readText("test.d");
>     write(s);
> }
>
>
> On windows the output is:
> import std.file: readText;
>
> import std.stdio: write;
>
> void main() {
>
>     string s = readText("test.d");
>
>     write(s);
>
> }
>
>
> So it shows extra newlines (on Windows newlines are two chars).
>
> On Windows a similar Python program doesn't show the doubled newlines:
> s = open("test.d").read()
> print s

Copy-pasting the source from an editor to the newsgroup window may not allow others to see the problem, since it may have to do with non-visible characters.

Attach the file directly to a news post, then maybe we can repeat it easier.

-Steve