Missing carriage return

[pneumatic]

Edit: solved, not a bug, just my misinterpretation of what "disable end of line translation" means.


Contents of InputFile.txt:



Now read the file in and write it back out to file to confirm FileRead and FileAppend are working properly:

Code: Select all

FileRead , OutputFileContents , InputFile.txt
FileDelete , OutputFileContents.txt
FileAppend , %OutputFileContents% , OutputFileContents.txt

Result:



Good ✓

Now write a concatenated string to a file using FileAppend, to confirm FileAppend works properly with concatenated strings:

Code: Select all

Loop 3
	OutputString .= "String line " . A_Index . "`n"
FileDelete , OutputString.txt
FileAppend , %OutputString% , OutputString.txt

Result:



Good ✓

Now concatenate the string with the file contents, and write that to file:

Code: Select all

OutputFilePlusString := OutputFileContents . "`n" . OutputString 			
FileDelete , OutputFilePlusString.txt
FileAppend , %OutputFilePlusString% , OutputFilePlusString.txt

Result:



✕ Wrong

For some reason it has only appended line feed instead of carriage return + line feed.

I noticed this after finding Ahk2Exe specifically writes line feed only (without carriage return) to the output executable.

[TAC109]

From FileAppend documentation (see bolded section):
End of line (EOL) translation: To disable EOL translation, prepend an asterisk to the filename. This causes each linefeed character (`n) to be written as a single linefeed (LF) rather than the Windows standard of CR+LF. For example: *C:\My Unix File.txt.

If the file is not already open (due to being inside a file-reading loop), EOL translation is automatically disabled if Text contains any carriage return and linefeed pairs (`r`n). In other words, the asterisk option described in the previous paragraph is put into effect automatically. However, specifying the asterisk when Text contains `r`n improves performance because the program does not need to scan Text for `r`n.

[pneumatic]

But in the first example, OutputFileContents contains CR+LF (because it originated from FileRead which requires the *t option to convert CR+LF's to LF) and yet FileAppend still writes it back to file as CR+LF.

And in the last example there is a mixture of CR+LF and LF in the output file, and CR's are only being removed from OutputString which doesn't even contain the `r`n needed to auto-disable EOL translation.

[TAC109]

It doesn’t matter how the CRLF's get into the text being appended to the file, the highlighted section still applies. `r`n is just a convenient way of writing CRLF, and if written as such in a literal, will get converted before the FileAppend is actioned.

Because there is at least one CRLF in the text being appended, FlleAppend doesn’t translate LF's into CRLF's. FileAppend is performing as documented.

[guest3456]

But in the first example, OutputFileContents contains CR+LF (because it originated from FileRead which requires the *t option to convert CR+LF's to LF) and yet FileAppend still writes it back to file as CR+LF.

which sounds right to me. the translation is only LF -> CRLF. it doesnt say its supposed to change any existing CRLFs, and it doesnt touch anything in your first example

And in the last example there is a mixture of CR+LF and LF in the output file, and CR's are only being removed from OutputString which doesn't even contain the `r`n needed to auto-disable EOL translation.

there is a mixture of CRLFs and LFs in the INPUT TEXT PARAMETER contents, and as documented, the presence of CRLFs disable the translation of LFs into CRLFs in the output file.

your 2nd example has no CRLFs in the input text parameter, it only has LFs, and so this is the only example of the 3 where the translation is performed, and your output file has CRLFs instead of only the LFs (`n's) you specified

[pneumatic]

Sorry, I misinterpreted the rule.

I thought disabling EOLT meant that CR+LF becomes LF.

But actually all it means is that LF remains as LF instead of becoming CR+LF.

So if a line in a string contains CR+LF, it will just remain as CR+LF, since the LF portion of it remains as LF.

And if another line in that same string contains only LF, it will be left as LF, since there are other lines in the string containing CR+LF, which engages the rule "LF remains as LF" aka "disable EOLT".