Linefeed Write Bug

Hi All

This problem stems from a Filemaker issue when exporting text files - FM exports vertical tabs as the line endings (asc 11). Easy-Peezy I thought - just replace them using an applescript - not so. It seems that OSX replaces a linefeed (asc 10) character with a carriage return (asc 13) when writing the data back to disc.
Check the script below - it opens a text file in the docs folder called “VT.txt” - this can be any scratch file with vertical tabs as the line endings. It replaces the vert tabs with linefeeds then writes them back to disc as the same file.
Sadly, you can use any character other than a linefeed and it works fine - use linefeed and it replaces it with a carriage return !!!

BTW, using OSX 10.5.7 (and tried using various versions before this with the same issue).

Also, I NEED it to be linefeeds :slight_smile:

Someone out there has a simple fix to this problem I’m sure :slight_smile:



– Issue with FMPro 9 substituting CRs for VTs
– This opens file VT.txt, replaces the VTs with LFs and resaves it
– © Neil D Gillies May 2009

– Coerce the path
set thePath to POSIX path of (path to documents folder from user domain)
set thePath to thePath & “VT.txt”
set thePath to POSIX file thePath

– read the file
open for access file thePath
set theText to read file thePath
close access file thePath

– Replace VTs with LFs
set cleanText to replaceVT(theText)

– Note the cleanText DOES contain linefeeds at this point so the problem is with the write routine to disc.
–set the clipboard to cleanText

my writeToFile(cleanText, thePath, false)

on replaceVT(theString)
set AppleScript’s text item delimiters to {ASCII character 11}
set textlist to text items of theString
set AppleScript’s text item delimiters to {ASCII character 10}
set newText to textlist as string
set AppleScript’s text item delimiters to {“”}
return newText
end replaceVT

on writeToFile(theData, targetFile, appendData)

	set the targetFile to the targetFile as text
	set the openTarget to open for access file targetFile with write permission
	if appendData is false then set eof of the openTarget to 0
	write theData to the openTarget starting at eof as string
	close access the openTarget
	return true
on error
		close access file targetFile
	end try
	return false
end try

end writeToFile

Model: MAcBook Pro/10.5.7
AppleScript: 2.0.1
Browser: Safari 528.16
Operating System: Mac OS X (10.5)

Admittedly I don’t know much about encoding or line feeds versus carriage returns and so on, but it could it have something to do with the native encoding of the file you are writing too?

I say this because on my system (10.5.7) when I use this code

set thedata to "hello" & (ASCII character 10) & "how are ya"

set theFile to (path to desktop as Unicode text) & "test_write.txt"
	close access file theFile
end try
set file_ref to (open for access file theFile with write permission)
set eof file_ref to 0

write thedata to file_ref
close access file_ref

And then read it back in like so

set theFile to (path to desktop as Unicode text) & "test_write.txt"
set theData to read file theFile

I do in fact get a \n rather than a \r as the line separator.

Hi James

Many thanks for the reply.

I tried your code, but it still comes up with the same answer - carriage return (chr 13) instead of a linefeed (chr 11).

I’ve viewed the output file in a couple of apps just in case :slight_smile: Tex-Edit Plus is my preference.

Any character other than linefeed is OK - it outputs the correct character.

I’m wondering if there is some issue with an international setting in the OS - what do you use ?

Out of interest, I changed it to US and US (computer) - no difference.

Currently I’m stumped - it’s the same on 10 computers of the 90 or so we have here - I’m in the UK.

I’m working on scripting TexEdit to do the deed - dirty, but I need a fast fix - the other option is to write an app in RealBasic (wash my mouth out with soap :smiley:

Best regards



the code of James must work in every case. It just writes the specified text to disk. When you open the file in a hex editor you will see

68 65 6C 6C 0A 68 6F 77 20 61 72 65 20 79 61 are ya

Maybe your preferred Text Editor changes the line separator while reading the file

Hi Stefan

You’re right - I checked it in hexedit - sure enough chr(0A) - linefeed.

While there was a REAL problem with FMpro, Tex-Edit Plus compounded the issue - there is a sneaky default in Tex-Edit Plus prefs …

“Auto Convert LFs when opening document” - DOHHHHHHHHHHH :confused:

Problem solved - and my applescript does actually work fine :smiley:

Many thanks for pointing out the fatal error !

Best regards