On Wednesday, 20 March 2013 at 14:34:21 UTC, Nick Sabalausky wrote:
> Since *at least* as far back as XP, Windows has handled "\n" newlines
> perfectly fine. The command line displays them properly, .BAT scripts
> handle them properly, every code editor in existence handles them
> properly. The *only* thing I've found that doesn't is Windows Notepad,
> but really, whoTF uses that anyway?

Notepad is used as a log viewer. When you're presented a machine you don't run, you usually don't have time to setup your preferred work environment, notepad comes in handy to just view the log and diagnose an error.

On Thursday, 21 March 2013 at 05:01:06 UTC, Kagamin wrote:
> On Wednesday, 20 March 2013 at 14:34:21 UTC, Nick Sabalausky wrote:
>> Since *at least* as far back as XP, Windows has handled "\n" newlines
>> perfectly fine. The command line displays them properly, .BAT scripts
>> handle them properly, every code editor in existence handles them
>> properly. The *only* thing I've found that doesn't is Windows Notepad,
>> but really, whoTF uses that anyway?
>
> Notepad is used as a log viewer. When you're presented a machine you don't run, you usually don't have time to setup your preferred work environment, notepad comes in handy to just view the log and diagnose an error.

My workaround in such cases is to use Write, which is also installed by default and handles the files correctly.

I think Notepad still uses the same code from Windows 3.x days! :)

--
Paulo

On 2013-03-20 22:08, Nick Sabalausky wrote:

> I doubt there's a bugzilla entry for this since it is, unfortunately,
> the intended behavior. I didn't want to go posting a 'zilla issue for
> it before discussing here because I figured that might just end up
> "INVALID" or "WONTFIX".

If you make it an enhancement request it shouldn't at least end up as "INVALID".

-- 
/Jacob Carlborg

On 2013-03-20 23:00, Graham Fawcett wrote:

> Is anyone still using MacOS earlier than version 10 (OSX)? Mac OS 9 was
> discontinued in 2002.
>
> On OSX, there's certainly no problem with Unix line endings. But I guess
> if we include "ancient Windows support" as an option, then "ancient Mac
> support" should in be there too.
>
> But writeln/writefln should emit '\n' as a line terminator, by default,
> on all platforms. Ancient terminators should be always opt-in,
> regardless of platform.

I agree.

-- 
/Jacob Carlborg

On Thu, 21 Mar 2013 10:41:35 +0100
Jacob Carlborg <doob@me.com> wrote:

> On 2013-03-20 22:08, Nick Sabalausky wrote:
> 
> > I doubt there's a bugzilla entry for this since it is, unfortunately, the intended behavior. I didn't want to go posting a 'zilla issue for it before discussing here because I figured that might just end up "INVALID" or "WONTFIX".
> 
> If you make it an enhancement request it shouldn't at least end up as "INVALID".
> 

http://d.puremagic.com/issues/show_bug.cgi?id=9776

21-Mar-2013 09:01, Kagamin пишет:
> On Wednesday, 20 March 2013 at 14:34:21 UTC, Nick Sabalausky wrote:
>> Since *at least* as far back as XP, Windows has handled "\n" newlines
>> perfectly fine. The command line displays them properly, .BAT scripts
>> handle them properly, every code editor in existence handles them
>> properly. The *only* thing I've found that doesn't is Windows Notepad,
>> but really, whoTF uses that anyway?
>
> Notepad is used as a log viewer.

One word - Wordpad.

Any relatively interesting log file is measured in MBs thus hanging the notepad on as said random machine.

> When you're presented a machine you
> don't run, you usually don't have time to setup your preferred work
> environment, notepad comes in handy to just view the log and diagnose an
> error.


-- 
Dmitry Olshansky

On 20.03.2013 15:34, Nick Sabalausky wrote:
> Since *at least* as far back as XP, Windows has handled "\n" newlines
> perfectly fine. The command line displays them properly, .BAT scripts
> handle them properly, every code editor in existence handles them
> properly. The *only* thing I've found that doesn't is Windows Notepad,
> but really, whoTF uses that anyway?
>
> So, why are silently and forcefully converting "\n" to "\r\n" on
> windows by default? All it does is cause bugs. For example:
> https://github.com/repeatedly/mustache-d/issues/3
>
> And that's definitely not the first time I've run into problems due
> using the "write*" functions instead of rawWrite.
>
> Consider this straightforward code:
>
> --------------------------------------
> import std.file;
> import std.stdio;
>
> void transform(string str)
> {
> 	/+ ...perform some modification of 'str'... +/
> 	return str;
> }
>
> void main()
> {
> 	auto str = cast(string) read(args[1]);
> 	str = transform(str);
> 	write(str);
> }
> --------------------------------------
>
> That simple code is *wrong*:
>
> It works correctly for all input on Unix: Output newlines match input
> newlines. Always. The code never asks for newlines to be messed with,
> and therefore they never are.

You're mixing binary and text mode functions.  read() is binary, stdout.write() is text mode.  And yes, you are asking for newlines to be messed with, as File.write is documented to write in text mode.

But I agree that the docs need improvement.  And maybe the API.

On Thu, 21 Mar 2013 23:37:06 +0100
torhu <no@spam.invalid> wrote:
> 
> You're mixing binary and text mode functions.  read() is binary,
> stdout.write() is text mode.  And yes, you are asking for newlines to
> be messed with, as File.write is documented to write in text mode.
> 
> But I agree that the docs need improvement.  And maybe the API.

You're missing the point. The point is that the "text mode" is bug-prone, grossly obsolete, and completely useless and therefore should absolutely not be the default, *if* it has any reason to even exist at all.

We could toss a function "output" into Phobos and document it as being "fubar mode, which converts every third word into 'DERP'", but obviously just because its behavior matches the description doesn't justify its existence or its usage of such a generic name. The current "write" function is every bit as useless as this hypothetical "output" function, but it's more dangerous because it's harder to notice you're getting the wrong result.

On 22.03.2013 00:36, Nick Sabalausky wrote:
> On Thu, 21 Mar 2013 23:37:06 +0100
> torhu <no@spam.invalid> wrote:
>>
>> You're mixing binary and text mode functions.  read() is binary,
>> stdout.write() is text mode.  And yes, you are asking for newlines to
>> be messed with, as File.write is documented to write in text mode.
>>
>> But I agree that the docs need improvement.  And maybe the API.
>
> You're missing the point. The point is that the "text mode" is
> bug-prone, grossly obsolete, and completely useless and therefore should
> absolutely not be the default, *if* it has any reason to even exist at
> all.

Text mode isn't going away, I don't know where you'd get that idea from.  I'm sure Microsoft wants Linux to go away, too.  If you want a to finance a FUD campaign to hurt the reputation of text mode, be my guest.   Or keep on ranting, who's gonna stop you.

Reviving old topic... It is possible to force stdout to write in binary mode on Windows, see https://msdn.microsoft.com/en-us/library/tw4k6df8.aspx

In C, the solution is:

-----------------------------
#include <stdio.h>
#include <fcntl.h>
#include <io.h>

/*...*/

int result = _setmode( _fileno( stdout ), _O_BINARY );
if ( result == -1 )
	perror ("Cannot set stdout to binary mode");
else
	perror ("stdout set to binary mode");
------------------------------


In Python, the solution is:

------------------------------
import platform
if platform.system() == "Windows":
    import os, msvcrt
    msvcrt.setmode(sys.stdout.fileno(), os.O_BINARY)
------------------------------

Since D can interface C, it must be possible to do the same in D? (how, I am not sure)