"Save text file" issue

[#1]

Hi everyone,

I have ripping my (last few) hair out over the past couple of days on a script that I could not get to work on Windows while it was working fine on Mac OS. After much comparison, I elucidated that it was due to a difference on how text file are created. This file needs to be created because it serves as input to another program that I run within JMP using the JSL function "Run program". This all works fine on Mac. The initial little bit of code that produces the text file is 

filename = Eval Insert( "^simdir^^lakename^/^lakename^.par" );
	lakepar = Eval Insert(
		"\[{
  "Input" : {
    "Initial conditions"  : "^simdir^^lakename^/icond.dat",
    "Grid"                : 24,
    "Morphology"          : "^simdir^^lakename^/hypso.dat",
    "Forcing"             : "^simdir^^lakename^/forcing.dat",
    "Absorption"          : "^simdir^^lakename^/lightextinction.dat",
    "Inflow"              : "^simdir^^lakename^/Qin.dat",
    "Outflow"             : "^simdir^^lakename^/Qout.dat",
    "Inflow temperature"  : "^simdir^^lakename^/Tin.dat",
    "Inflow salinity"     : "^simdir^^lakename^/Sin.dat"
  },
.
.
.
.
  }
}
]\"
	);
	Save Text File( filename, lakepar, "replace" );

On Mac OS, the output text file is all neatly organized as it should and looks like:

{
  "Input" : {
    "Initial conditions"  : "/Users/yvesprairie/Dropbox/sim3/Petit-Saut/icond.dat",
    "Grid"                : 24,
    "Morphology"          : "/Users/yvesprairie/Dropbox/sim3/Petit-Saut/hypso.dat",
    "Forcing"             : "/Users/yvesprairie/Dropbox/sim3/Petit-Saut/forcing.dat",
    "Absorption"          : "/Users/yvesprairie/Dropbox/sim3/Petit-Saut/lightextinction.dat",
    "Inflow"              : "/Users/yvesprairie/Dropbox/sim3/Petit-Saut/Qin.dat",
    "Outflow"             : "/Users/yvesprairie/Dropbox/sim3/Petit-Saut/Qout.dat",
    "Inflow temperature"  : "/Users/yvesprairie/Dropbox/sim3/Petit-Saut/Tin.dat",
    "Inflow salinity"     : "/Users/yvesprairie/Dropbox/sim3/Petit-Saut/Sin.dat"
  },

but on Windows it is all like a long and continuously wrapping line. The odd thing is that I cannot even paste it here because it looks ok but when I open it in a text editor like Atom, then the files looking very different. This difference makes the file unreadable by the "Run program" executable. I thought it has to do with hidden characters but in both the Mac and Windows version I use exactly the same "save text file" options (CR+LF, and commas as end-of-field) in my preferences and I also use the option to save text file as unicode. I don't know what else to try. Any help/suggestion will be greatly appreciated.

Best regards, Yves 

[#2]

youi need to enter in New Line characters where you want them.  On windows the new line character sequence is \!n

[#3 · Accepted solution]

Mac and Win (and Linux) have odd, different histories on how newlines are used. There are a number of things happening here: 

• you are putting some sort of newline sequence into your string. It may vary between Win and Mac.
• SaveTextFile may be doing some host specific conversion on the newlines. It may vary...
• Different editors may treat newline sequences differently. It may vary...

JMP can control the first two, and most likely you can find a set of newline characters that works for your editors.

To set the newline sequences, try one of these to replace any sequence of CR and LF with a predictable sequence

lakepar = regex(lakepar,"[\n\r]+","\!n",GLOBALREPLACE);
// or
lakepar = regex(lakepar,"[\n\r]+","\!r",GLOBALREPLACE);
// or
lakepar = regex(lakepar,"[\n\r]+","\!r\!n",GLOBALREPLACE);

LF, CR, or CRLF are the usual possibilities for a newline sequence.

To prevent savetextfile from converting newline sequences to what it thinks the host needs, save a blob:

saveTextFile( "$desktop/x.txt", chartoblob(lakepar) );

To peek at the string or file, use a blob:

show(chartoblob(lakepar));
// or
show(loadtextfile( "$desktop/x.txt", blob));// to view

Load Text File("$desktop/x.txt", blob) = Char To Blob( "abc~0D~0Adef~0D~0Aghiu", "ascii~hex" );

~0D is a CR and ~0A is a LF

[#4]

Thank you so much Craige for the detailed explanation. I will try them and report! Thanks again, Yves

[#5]

Your solution worked like a charm, thank you very much again! Yves