Delimiters when reading and splitting text file

I put together a sub-routine a while back that I can run to convert a text file to a list directly. It works well, but I discovered that when I use multiple characters for the delimiters, the script runs, but the output is not as desired. Seemingly, because it only matches the first character of the string. Is there a way to make it match the entire string or am I missing something else?

I know you can use strings as a delimiter for find/replace. I suppose I could read the entire file into one string, then split it up with another command… but it seems like the way I’m trying should work. (Though, obviously not.) :rolleyes:

just a test
to see what test i can test today
what will i see when i test
set exampleList to text_to_list("Macintosh SSD:Users:maeks84:Desktop:Example.txt", "test")
return exampleList

on text_to_list(filePath, customDelim) --v 1.0
	if customDelim is "" then
		set customDelim to ASCII character 10
	end if
	set textData to open for access filePath
	set textSize to get eof of textData
	set textList to read textData using delimiter customDelim from 1 to textSize
	close access textData
	return textList
end text_to_list

That’s a much better (and faster) approach. Use text item delimiters to split it.


Shane’s absolutely right about that approach being both better and faster. read’s ‘using delimiter’ parameter is an ancient relic which doesn’t even use the first character of the supplied text — just the first byte! If you have a delimiter character which can’t be expressed in one byte, the input won’t be split even if you read the text as the required form of Unicode.

Your handler has several issues anyway:
• The ASCII character function has long been deprecated. Nowadays one has to use character id, which takes a Unicode number rather than an ASCII one. In the case of character id 10, AppleScript now has a constant for that anyway: linefeed.
• Apple discourages the use of bare HFS paths with commands which address files, although this still works in many cases. The parameter should be some form of file or alias specifier, or possibly a POSIX path:

set textData to open for access file filePath
-- Or:
set textData to open for access alias filePath
-- Or:
set textData to open for access (filePath as alias) -- or (filepath as «class furl»)
-- Or:
set textData to open for access (POSIX path of (filePath as «class furl»)) -- !

• The ‘of’ in get eof of textData is superfluous (but currently harmless). But in fact it’s not necessary to get the length of the file before reading it. The read command will read through to the end if no end point is specified. Similarly, it’ll read from the beginning by default if the file’s just been opened.
• When a file’s opened using open for access, the things that are done while it’s open should be in a try statement, so that if there’s an error, the script will keep going long enough to close the file again. But in fact there’s no need to open a file explicity if it already exists and you only want to read it. You can simply read it and the opening and closing will be handled automatically.

Putting all this together with the text item delimiters idea, you’re possibly looking at something like this:

set exampleList to text_to_list((path to desktop as text) & "Example.txt", "test")
return exampleList

on text_to_list(filePath, customDelim) --v 1.0
	if customDelim is "" then set customDelim to linefeed
	set theText to (read file filePath) -- or (read file filePath as «class utf8») if the text was saved in UTF-8 format.
	set astid to AppleScript's text item delimiters
	set AppleScript's text item delimiters to customDelim
	set textList to theText's text items
	set AppleScript's text item delimiters to astid
	return textList
end text_to_list

I recently set about learning to use text files in my Applescripts, and, although 11 years old, Nigel’s post entitled “The Ins & Outs of File Read/Write in AppleScript” remains an excellent source of detailed information on this topic.

It includes a discussion of using delimiters as was done by the OP.

I put the sub-routine together a few years back, but even then one of the problems with searching google is that you never know how old or obsolete the info is. Nigel, your solution worked perfectly and the info given I will try to file away for later. Thanks!