Finder - Make New File with properties {contents:_}

Scripting Forums AppleScript | Mac OS X
,
#1

I’ve adapted a script that StefanK posted (3rd post here: http://macscripter.net/viewtopic.php?id=33823) - instead of creating folders for every line in a text file, it creates a text file for every line in another text file at a specified folder.

It works, but when I added an additional property to write contents to each file, it doesn’t write anything to the files - the “contents:myText” property doesn’t seem to do anything.


display dialog " --Make Lotsa' Text Files-- 
This AppleScript will create multiple text files using names from a text file that you specify."
set destination to (choose folder with prompt "Where would you like to make the text files?")
set textFile to (choose file with prompt "Select the text file you wish to use")
set fileNames to paragraphs of (read textFile)
repeat with oneName in fileNames
	set myText to "This is the file for" & oneName & return
	set textName to oneName & ".txt"
	tell application "Finder" to make new file at destination with properties {name:textName, contents:myText} 
end repeat
display dialog "Your files are done." buttons {"OK"}

Browser: Safari 537.36
Operating System: Mac OS X (10.7)

#2

Hi,

look into the dictionary of the Finder and you will see that there is no property contents of class file.

One solution is to create the files with Standard Additions (code not tested)


display dialog " --Make Lotsa' Text Files-- 
This AppleScript will create multiple text files using names from a text file that you specify."
set destination to (choose folder with prompt "Where would you like to make the text files?")
set textFile to (choose file with prompt "Select the text file you wish to use")
set fileNames to paragraphs of (read textFile)
repeat with oneName in fileNames
	set myText to "This is the file for" & oneName & return
	set destinationFile to (destination as text) & oneName & ".txt"
	set writeResult to writeToDisk from myText into destinationFile
	if writeResult is false then display dialog "An error occurred while writing file " & destinationFile buttons {"Cancel", "Continue"} default button "Continue"
end repeat
display dialog "Your files are done." buttons {"OK"}

on writeToDisk from theData into theFile
	try
		set fileReference to open for access file theFile with write permission
		write theData to fileReference
		close access fileReference
		return true
	on error
		try
			close access file theFile
		end try
		return false
	end try
end writeToDisk
#3

I guess the ‘open for access’ & write operations are unavoidable unless I opted for shell scripting. Thanks Stefan, the script works great.

#4

Why would you want to avoid them?

#5

As Shane hints, there’s no point in avoiding the commands which were designed for the job and which do it fastest ” albeit with a little more code.

For geek interest though, the classic way of using these commands .

-- set theFile to some HFS path.

set fileReference to (open for access file theFile with write permission)
write theData to fileReference
close access fileReference

. is done because:

  1. ‘open for access’ creates the file if it doesn’t exist, obtains a write-permission access to it, and returns the file-system’s reference number for the access to the script. The ‘current application’ to which ‘open for access’ was addressed then “owns” the access and no other application can use it. (So if ‘open for access’ is in a ‘tell’ statement to an application, the reference can only be used in ‘tell’ statements to that particular application.) There can be several accesses open to the file simultaneously, each with its own reference number and file-position pointer and perhaps belonging to a different application, but only one of these accesses can have write permission.
  2. The reference number for the opened access is passed directly to the ‘write’ command, which is thus spared the bother of checking for itself to see if the file’s open and the embarrassment of using the wrong access if there are more than one.
  3. The reference number is also passed directly to the ‘close access’ command, with the same advantages as for the ‘write’ command.

This three-command sequence, in conjuntion with a ‘try’ statement, is generally the fastest and safest way to create a file and write something to it.

However, if the file already exists and isn’t currently open for access, with or without write permission, the ‘write’ command is perfectly capable of opening up its own write-permission access, using it, and closing it again afterwards:

set myFilePath to (path to desktop as text) & "My file.txt"

-- For this demo, create/open the file and close the access set up in the process.
-- No need to have write permission just for this.
close access (open for access file myFilePath)

-- Now write to the file, letting 'write' sort out its own write-permission access.
write "Hello" to file myFilePath

If the two underlined conditions above are true (seldom 100% guaranteed), then ‘write’ by itself, with a ‘file’ or ‘alias’ parameter, is minutely faster than in conjunction with explicit ‘open for access’ and ‘close access’ commands. It’s not worth the risk to do this, but it’s possible.

Similarly, if the Finder is used to create a file ” a much slower way than using ‘open for access’ ” ‘write’ can open and close the file itself immediately afterwards:

tell application "Finder" to make new file at destination with properties {name:textName}
write myText to file ((destination as text) & textName)
#6

Why do that in the Finder ?
We may achieve the goal with TextEdit and in this case, the contents is not restricted to raw text, we may create RTF documents with some extraneous features.

KOENIG Yvan (VALLAURIS, France) vendredi 23 août 2013 17:41:58

#7

Writing from an application. I didn’t know that!