class furl in InDesign CC


I recently saw that Shane Stanley has recommended that we coerce a path to «class furl» outside of InDesign’s tell block before placing it, for example:

set fpath to "MyHD:Folder:logo.tif"
set fpath to (fpath as «class furl»)
place fpath on (every page item whose label is "Logo")

This works well so far in Catalina, but I have a couple questions:

  1. If I’m exporting text out of a text frame, is it necessary to do something similar? For example, should it be:

set DescripFP to "MyHD:Folder:Descrip.txt" as «class furl»
export (text of (item 1 of every text frame whose label is "Description")) format tagged text to DescripFP

I’m wondering if the fact that the file doesn’t exist yet when I use class furl might give unreliable results?

  1. Many of my Applescripts are inside Filemaker Pro, and there seems to be an implied tell block for Filemaker itself. That is, I don’t need to tell application “Filemaker Pro Advanced”, it just understands that if something isn’t inside another app’s explicit tell block in the script, it’s either an implicit Filemaker tell block, or equivalent to addressing Applescript itself. If that makes sense…

I have a lot of scripts to change, so I’m trying to establish all the things I should change – mainly opening, placing, and exporting – before I begin. Any expertise from Shane or anyone else is welcome and apreciated!



Browser: Safari 605.1.15
Operating System: macOS 10.14

As I don’t use the named applications I can’t only answer to one of your questions.
At the opposite of alias, «class furl» doesn’t issue an error when it’s applied to an item which is not available.

Yvan KOENIG running High Sierra 10.13.6 in French (VALLAURIS, France) mercredi 10 juin 2020 00:01:48

Ah, so if I understand you correctly, I could set a text string path to class furl and write a new file to that path, and it would work because unlike an alias, it does not require a file to exist there beforehand, and there is no error message? Thank you for that distinction, Yvan!

The reason for suggesting you create the furl outside InDesign’s tell block is not really for InDesign, but as a general rule if possible. It may not matter in the case of InDesign, but it does matter if you’re passing the resulting file to a sandboxed app.

When you pass just a path to a sandboxed app, sandboxing means it has no way of turning it into a file itself (unless it already has access via something like an open file panel). But when AppleScript creates a file (or alias) and passes it to a sandboxed app, the file is granted access privileges.

I’m not sure what the ramifications are for FileMaker Pro – you probably need to do some tests.

Many thanks for this info, Shane, I didn’t know how it was related to sandboxing. I had been coercing the path string to class furl right before placing, so it’s in the InDesign tell block, but it seemed to be working fine. I was somewhat worried about reliability/consistency even though it works.

I haven’t tested my Export Tagged Text scripts yet, but Yvan mentioned that using class furl gets around the “file must already exist” feature of aliases, so I think it should work fine in Catalina (Catalina is why I have to change all these).

Thanks again!

What I described is not specific to Catalina.

In every system aware of «class furl» objects, the script below would behave the same way:

set p2d to path to desktop as string
set fName to "n'importe quoi.pdf"
set hfs to p2d & fName
set aFile to hfs as «class furl»
log result (*file SSD 1000:Users:**********:Desktop:n'importe quoi.pdf*)
set otherFile to POSIX file (POSIX path of hfs)
log result (*file SSD 1000:Users:**********:Desktop:n'importe quoi.pdf*)
aFile = otherFile
log result (*true*)
set fAlias to hfs as alias
--> error "Le fichier SSD 1000:Users:**********:Desktop:n'importe quoi.pdf est introuvable." number -43 from "SSD 1000:Users:**********:Desktop:n'importe quoi.pdf"

The file object («class furl») is created with no problem.
Trying to define an alias object for this object which does not exist on disk issue an error.

The late version available of AppleScript User Guide describe that but is unaware of «class furl» objects:

[i]Aliases and Files
To refer to items and locations in the macOS file system, you use alias objects and file objects.
An alias object is a dynamic reference to an existing file system object. Because it is dynamic, it can maintain the link to its designated file
system object even if that object is moved or renamed.
A file object represents a specific file at a specific location in the file system. It can refer to an item that does not currently exist, such as the name and location for a file that is to be created. A file object is not dynamic, and always refers to the same location, even if a different item is moved into that place. The POSIX file pseudo-class is roughly synonymous with file: POSIX file specifiers evaluate to a file object, but they use different semantics for the name, as described in Specifying Paths.
The following is the recommended usage for these types:
Use an alias object to refer to existing file system objects. Use a file object to refer to a file that does not yet exist.
– At the top-level of the script:
me --result: «script» (the top-level script object)
it --result: «script» (same as it, since no target set yet)
– Within a tell block:
tell application “Finder” – sets target
me --result: «script» (still the top-level script object)
it --result: application “Finder” (target of the tell statement)
end tell
tell application “Finder”
set fileCount to count files in front window
set myCount to my minimumValue(fileCount, 100)
–do something with up to the first 100 files…
end tell
tell document 1 of application “TextEdit”
name --result: “Simple.rtf” (implicitly uses target of tell)
name of it --result: “Simple.rtf” (specifies target of tell)
me --result: «script» (top-level script object, not target of tell)
end tell
tell application “Finder”
version --result: “10.5.1” (Finder version is the default in tell block)
its version --result: “10.5.1” (specifically asks for Finder version)
version of me --result: “2.0” (AppleScript version)
my version --result: “2.0” (AppleScript version)
version of AppleScript --result: “2.0” (AppleScript version)
end tell

Use a POSIX file specifier if you want to specify the file using a POSIX path.
The following sections describe how to specify file system objects by path and how to work with them in your scripts.[/i]

When it was written, the only way to define a file object was the POSIX file structure.
Happily, now we have the «class furl».

Yvan KOENIG running High Sierra 10.13.6 in French (VALLAURIS, France) mercredi 10 juin 2020 22:02:08

More interesting info, Yvan, thanks!

As a follow-up question, is it also best practice to use class furl for folders? (And folders that already exist.)

I just modified a duplicate file script thusly:


set sourceFP to "MyHD:folder:mypdf.pdf"
tell application "Finder"
	set destFD to (((path to desktop folder) as text))
		duplicate file sourceFP to folder (destFD) with replacing
	on error e
		display dialog e
	end try
end tell


set sourceFP to "MyHD:folder:mypdf.pdf"
set sourceFP to (sourceFP as «class furl»)

set destFD to ((path to desktop folder) as text)
set destFD to (destFD as «class furl») -- folder already exists

tell application "Finder"
		duplicate sourceFP to destFD with replacing
	on error e
		display dialog e
	end try
end tell

This works, but I’m wondering if it’s the best way to handle folders, and what downsides there could be.

As always, thanks for any tips and tricks! -k

Apple recommends the use of aliases and file objects, and Finder works fine with both of these. The path-to command is part of Standard Additions, and I would set that outside the Finder tell statement. To a certain extent, this is a matter of personal preference but I would use the following:

set sourceFP to "MyHD:folder:mypdf.pdf"
set destFD to path to desktop -- returns an alias

tell application "Finder"
		duplicate file sourceFP to destFD with replacing
	on error e
		display dialog e
	end try
end tell

The Apple recommendation is:

Nice, peavine. I see your point about the “path to” command, and will incorporate it!

As far as I know, the Finder continue to recognize alias objects so we may use as alias as well as «as class furl».
As I hate it I rarely use it but when I do I use the class which is available.
What forces me to choose this or that is what I’m trying to achieve.
In your example, it doesn’t matter but choosing the correct class is important with files because if we may ask the Finder about the availability of a «class furl» object, we can’t ask it to return several properties of such objects. It’s why, when I need to do that I ask about aliases.
It’s more ore less the same with System Events. With it, it’s even more annoying. If I remember well, it would tell that a «class furl» object exist as soon as it is defined but it would do that even it the object is not already available on disk. In such case I ask it if the named disk item exists.
Nothing is simple with Applescript. It was designed to resemble to English language and, as this one, some times the meaning of words is different given the context.
This kind of problem strikes also when we use ASObjC. Some commands supposed to target NSURL object apply to «class furl» ones but most of them refuse to treat them.

Yvan KOENIG running High Sierra 10.13.6 in French (VALLAURIS, France) vendredi 12 juin 2020 00:19:25

Thanks, Yvan. I see now that I will have to carefully choose which form I use based on what I want to do with files and folders. I may have to use multiple variables sometimes – as alias and as «class furl» – depending on the situation. This thread has taught me a lot!

If you look at message #14 in the thread you will find a script in which I use variables storing aliases, variables storing «class furl» objects, variables hfs text path and the same variables coerced as «class furl» when needed.

Yvan KOENIG running High Sierra 10.13.6 in French (VALLAURIS, France) vendredi 12 juin 2020 17:47:37

Ha, you’re way ahead of me! I’ll check that out, thanks!