Hello
If i use:
set HFSpath to (POSIX file "/Applications/TextEdit.app")
i get:
file "SISTEMA:Applications:TextEdit.app"
but this seems don’t work and get error -1728 :
set filereference to (file "Macintosh HD:Applications:TextEdit.app")
Instead with alias works correct:
set aliasreference to (alias "Macintosh HD:Applications:TextEdit.app")
Someone know why??
Thanks!
Hello.
What you are trying to do in your third example is to set a variable to a file. File object would be a better name. The reason this fails, is that you can’t automatically read in the contents of a file in this way.
Here is the correct way to set a file reference:
set filereference to (a reference to file "Macintosh HD:Applications:TextEdit.app")
P.S
The reason you get the result you do in your example 2, is that the path has been resolved, and it points to a file, at that path.
An alias is a reference already, so that is why your 4th example works. But, if the file isn’t there, then setting the variable to the alias will fail, whereas the filereference will work, since it doesn’t need to exist. (The alias, is really a reference number, and when the file doesn’t exist, it doesn’t have a reference number, and hence, an error is thrown.)
This works flawlessly :
tell application "Finder"
set filereference to (file "Macintosh HD:Applications:TextEdit.app")
end tell
Yvan KOENIG (VALLAURIS, France) lundi 3 novembre 2014 15:38:11
Hello Yvan.
It does, but that file, is a different type of file, that is a file, as the Application Finder sees it. I was discussing what works, and what doesn’t in a pure Applescript context (outside any tell application blocks).
This works also for that matter:
tell application "System Events"
set filereference to (file "Macintosh HD:Applications:TextEdit.app")
end tell
Why AppleScript do not return the same?
Example 1: POSIX path to FILE
set POSIXtoFILE to (POSIX file "/Applications/TextEdit.app")
return → file “Macintosh HD:Applications:TextEdit.app”
Example 1: HFS path to FILE
set HFStoFILE to file "Macintosh HD:Applications:TextEdit.app" as reference
return → file “Macintosh HD:Applications:TextEdit.app” of «script»
Why this “of «script»”, How I can get the exact same result with different path format POSIX and HFS ?
Thanks!
the result of POSIX file is a file URL (file:///Applications/TextEdit.app") which is not the same as a file specifier
For portability this might be an alternative
set aliasSpecifier to path to application "TextEdit"
Hello.
Posix file is a class that coerces a posix path into a file pointed to by a hfs path. On the way, the path is said to be resolved , and then resolved path points to an object of type file, (so, it hasn’t tried to assign a file to something, it is more of a file pointer you get back.)
The of script, means that the script owns that file reference, it doesn’t work with any other script, if you don’t go thru the script where it was created in order to get at the reference or the contents of it, (which is different from an alias file in the file system, which will work with any script that adresses it).
If you had written:
set POSIXtoFILE to (POSIX file "/Applications/TextEdit.app") as reference
then you would have gotten back:
file “Macintosh HD:Applications:TextEdit.app” of «script»
This is because that reference, hasn’t anything to do with the operating system, or file system, but is created within the context of your script. (A property of it.)
I hope this is understandable: 
When you create a reference, you create your own reference to an object, that persists during the script. The reference is like a pointer, if that makes any sense to you. (A Variable that holds an address to another variable). Since this reference is local to your script (it only exists within it), AppleScript makes that clear to you.
If you look in AppleScript Language Guide, in page 47, you may read :
Aliases and Files
To refer to items and locations in the OS X file system, you usealias (page 98) objects andfile (page 110) 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 (page 116) pseudo-class is roughly synonymous with file:POSIX filespecifiers evaluate to afileobject, but they use different semantics for the name, as described in “Specifying Paths” (page 47).
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.
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 repeat the important words:
The POSIX file (page 116) pseudo-class is roughly synonymous with file.
If I read well, POSIX file resemble to file but isn’t exactly the same object.
Page 116 contains more details and, as it’s often the case with this kind of document, it urges us to jump to an oteher page 
POSIX file
A pseudo-class equivalent to the file class.
There is never an object whose class is POSIX file; the result of evaluating a POSIX file specifier is a file object. The difference between file and POSIX file objects is in how they interpret name specifiers: a POSIX file object interprets “name” as a POSIX path, while a file object interprets it as an HFS path.
Forrelatedinformation,seealias(page98)andfile(page110).ForadescriptionoftheformatforaPOSIX path, see “Aliases and Files” (page 47).
Properties of POSIX file objects
Seefile (page 110). Coercions Supported
Seefile (page 110).
I let you jump to page 110 which will urge you to jump to page 98.
Yvan KOENIG (VALLAURIS, France) lundi 3 novembre 2014 16:50:25
In Book “AppleScript: The Comprehensive Guide to Scripting and Automation on Mac OS X”
Seems that I can write file or alias from HFS path. Then…
Why with alias this works well:
set HFStoALIAS to alias "Macintosh HD:Applications:TextEdit.app"
And the same HFS path with file fail with error -1728
set HFStofile to file "Macintosh HD:Applications:TextEdit.app"
thanks!
please read this page of Matt Neuburg’s book, it describes the different file types
AppleScript: The Definitive Guide: Scripting and Automating Your Mac - Matt Neuburg - Google Books
Good one Stefan!
e3den:
Matt’s explanation is pretty thorough as usual.
A small addition:
Objects in AppleScript can be very context-sensitive. AppleScript itself doesn’t understand what a cell in Exel is, but Excel does.
tell application "Finder"
set HFStofile to file "Ryoko:Applications:TextEdit.app"
end tell
tell application "System Events"
set HFStofile to file "Ryoko:Applications:TextEdit.app"
end tell
set HFStofile to "Ryoko:Applications:TextEdit.app" as «class furl»
The Finder understands what a file object is and so does System Events, but most applications are going to want an alias or posix-file which is in fact of «class furl» - although some apps are getting posix-path savvy.
This business isn’t entirely logical, so it’s no surprise you’re suffering from some confusion. AppleScript has a few of these sorts of gotcha’s, and that’s one reason why many professional programmers don’t like it much and often have trouble with it.
I myself don’t especially like AppleScript as a language, but I sure like what it helps me to accomplish every day - so I use the hell out of it.
Here’s another little oddity. Note that each of the tell-blocks produces an app-specific reference-form.
tell application "Finder"
set finderFolder to folder "Ryoko:Users:chris:Downloads:"
end tell
tell application "System Events"
set sevFolder to folder "Ryoko:Users:chris:Downloads:"
end tell
finderFolder as alias # works on Mavericks
sevFolder as alias # fails on Mavericks
Note that the System Events form isn’t portable.
I’m surprised the Finder’s form is coercing outside of the Finder. It didn’t used to, and I don’t know offhand when than changed.
So. Don’t be too surprised when you ask “Why?” and get “Because!” as an answer. 
Hello.
I have to just say amen to StefanK’s recommendation.
In addition, I want to say that aliases, is very compatible with everything else, you can for instance get the path, and posix path out of them, and inside System Events and Finder for instance, you can get a lot of additional properties of aliases, like file size, creation date etc., so as long as files exists, those are the file references that are most gainful for you to use. Sometimes however, you’ll need to use a furl, a file and a reference to a file, is more often than not coerced into an alias.
And I think you’ll be better off now, if you avoid the whys, but just figures out what works for you, because this is a confusing theme, that really doesn’t take you anywhere, and it is hard to grasp too. 
If I remember well, the true problem with aliases is their inability to make the difference between two exactly identical pathnames from two physically different volumes.
Posix path are able to treat them with no glitches.
Yvan KOENIG (VALLAURIS, France) lundi 3 novembre 2014 19:15:01
Thanks to all for your responses!!
Use:
set HFStoFILE to "Macintosh HD:Applications:TextEdit.app" as «class furl»
That returns exactly the same class of object as POSIX file does.
The reason you can’t just use file directly is because AppleScript has more than one class whose name translates to file. Using «class furl» bypasses the ambiguity.