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.

But on Windows the behavior is just plain weird: Unix-style newlines in the input are silently and forcefully converted to Windows-style newlines behind the user's back. And even worse yet, *Windows*-style newlines on the input are converted to a bizarre "Mac9 plus Windows-style" combination of "\r\r\n" (not only is that wrong period, but this sequence is often interpreted as two newlines which makes it even worse). Using rawWrite fixes the problem, and creates *no* problem. I feel like the current "write*" behavior is a design Steve Jobs would have come up with.

So how is this useful to anyone, and how is it worthy of being the default output behavior?

Even with Windows as my primary system, there hasn't been one single time "write*"'s output-altering "feature" has helped me by doing something more correctly than rawWrite would have done. And that's just when I'm dealing with pure text. I'm literally better off just using rawWrite everywhere, which is exactly what I intend to do from now on (and I'll be viewing uses of "write*" with suspicion as latent bugs) - unlike "write*", rawWrite *never* does the wrong thing.

Can we please get rid of this "text-mode output"? Or at least eliminate it as the default?

20-Mar-2013 18:34, Nick Sabalausky пишет:
> 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.
>
> But on Windows the behavior is just plain weird: Unix-style newlines in
> the input are silently and forcefully converted to Windows-style
> newlines behind the user's back. And even worse yet, *Windows*-style
> newlines on the input are converted to a bizarre "Mac9 plus
> Windows-style" combination of "\r\r\n" (not only is that wrong period,
> but this sequence is often interpreted as two newlines which makes it
> even worse). Using rawWrite fixes the problem, and creates *no* problem.
> I feel like the current "write*" behavior is a design Steve Jobs would
> have come up with.
>
> So how is this useful to anyone, and how is it worthy of being the
> default output behavior?

No. Let's obliterate it. The only problem is compatibility and the fact that Windows has had this "text mode" for I/O in e.g. MSVCRT for a long time. It never helped me in any sensible way except that "yay! I can view it in notepad!"  but broken many things far too often.

>
> Even with Windows as my primary system, there hasn't been one single
> time "write*"'s output-altering "feature" has helped me by doing
> something more correctly than rawWrite would have done. And that's just
> when I'm dealing with pure text. I'm literally better off just using
> rawWrite everywhere, which is exactly what I intend to do from now on
> (and I'll be viewing uses of "write*" with suspicion as latent bugs) -
> unlike "write*", rawWrite *never* does the wrong thing.
>
> Can we please get rid of this "text-mode output"? Or at least eliminate
> it as the default?
>


-- 
Dmitry Olshansky

On Wednesday, 20 March 2013 at 14:34:21 UTC, Nick Sabalausky wrote:
> Can we please get rid of this "text-mode output"? Or at least eliminate
> it as the default?

+1. I've had to work around this issue several times by doing strange things like stripping the line ending and putting a \n at the end. I figured it was something I was just missing but seeing someone else mention the problem makes me think this is erroneous behavior. Is this in bugzilla?

On Wed, 20 Mar 2013 21:13:54 +0100
"Chris Cain" <clcain@uncg.edu> wrote:

> On Wednesday, 20 March 2013 at 14:34:21 UTC, Nick Sabalausky wrote:
> > Can we please get rid of this "text-mode output"? Or at least
> > eliminate
> > it as the default?
> 
> +1. I've had to work around this issue several times by doing strange things like stripping the line ending and putting a \n at the end. I figured it was something I was just missing but seeing someone else mention the problem makes me think this is erroneous behavior. Is this in bugzilla?

There *is* "stdout.rawWrite(...)" (ya gotta include the "stdout." part),
but unfortunately it doesn't come in "*ln", "*f" or "*fln" varieties.
And it should be the default.

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".

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?
> ....
>
> Can we please get rid of this "text-mode output"? Or at least eliminate
> it as the default?

+1. Leave an option in their for "ancient Windows support" if necessary, but take it out as the default.

Graham

On Wed, Mar 20, 2013 at 10:20:08PM +0100, Graham Fawcett 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?  ....
> >
> >Can we please get rid of this "text-mode output"? Or at least eliminate it as the default?
> 
> +1. Leave an option in their for "ancient Windows support" if necessary, but take it out as the default.
[...]

What about MacOS?


T

-- 
He who does not appreciate the beauty of language is not worthy to bemoan its flaws.

On Wednesday, 20 March 2013 at 21:33:48 UTC, H. S. Teoh wrote:
> On Wed, Mar 20, 2013 at 10:20:08PM +0100, Graham Fawcett 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?  ....
>> >
>> >Can we please get rid of this "text-mode output"? Or at least
>> >eliminate it as the default?
>> 
>> +1. Leave an option in their for "ancient Windows support" if
>> necessary, but take it out as the default.
> [...]
>
> What about MacOS?

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.

Graham

>
>
> T

On Wednesday, 20 March 2013 at 21:09:03 UTC, Nick Sabalausky wrote:
> There *is* "stdout.rawWrite(...)"

Sure, I saw that in your post. Thanks for the heads up. That'll be sometimes helpful for when I want to use it later. But still, rawWrite isn't exactly a replacement for write (just like, as you noted it's not a replacement for writef and ln varieties). In particular, it doesn't handle things like ranges as seemlessly as you'd want. Also, things such as write("my range = ", myRange) or writeln("This thing is ", myDesc, "!") are more difficult to do appropriately (though, std.string.format is pretty helpful here) Furthermore, lockingTextWriter displays the same sort of behavior and rawWrite doesn't help at all there because the use-case is completely different for an OutputRange.

That's why the default behavior should be the way that works on modern systems, as you suggest.

On Wed, 20 Mar 2013 23:00:18 +0100
"Graham Fawcett" <fawcett@uwindsor.ca> wrote:

> On Wednesday, 20 March 2013 at 21:33:48 UTC, H. S. Teoh wrote:
> > On Wed, Mar 20, 2013 at 10:20:08PM +0100, Graham Fawcett 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?  ....
> >> >
> >> >Can we please get rid of this "text-mode output"? Or at least eliminate it as the default?
> >> 
> >> +1. Leave an option in their for "ancient Windows support" if necessary, but take it out as the default.
> > [...]
> >
> > What about MacOS?
> 
> Is anyone still using MacOS earlier than version 10 (OSX)? Mac OS 9 was discontinued in 2002.
> 

It was more than discontinued, it was more or less obliterated. Even
OSX 10.3 and below are basically unusable anymore (unless you don't
expect to be able to install anything). Probably 10.4, too. \r as a
line ending is long dead. Might be worth supporting *reading* it in
certain cases (old text files can live on for a long time), but
not writing.

> 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.
> 

Yea, and by "Ancient" it's not as if we're even calling XP ancient. We're talking circa-Win9x line here. DMD and Phobos don't even try to support those anyway, and yet that's exactly what "write*" are essentially catering to.

I know Walter has said in the past that "there are places" where Windows still expects \r\n, but if even if that's true, such places are rare and are best handled as special cases as-needed.

On Thu, 21 Mar 2013 00:44:56 -0400
Nick Sabalausky <SeeWebsiteToContactMe@semitwist.com> wrote:
> 
> I know Walter has said in the past that "there are places" where Windows still expects \r\n...

Actually, I might be confusing that with "forward-slashes vs backslashes" in filepaths...