Re: HFS paths (was Tell Blocks Considered Harmful)
Re: HFS paths (was Tell Blocks Considered Harmful)
- Subject: Re: HFS paths (was Tell Blocks Considered Harmful)
- From: Axel Luttgens <email@hidden>
- Date: Sun, 21 Dec 2008 17:53:06 +0100
Le 21 déc. 08 à 14:17, Mark J. Reed a écrit :
[...]
This means that if "dir" is a variable containing the canonical POSIX
path to a directory, and "file" is a filename with no slashes, (dir &
"/" & file) will not always yield the canonical POSIX path of the
result. If dir is "/", then you wind up with "//filename". Not only
is that not canonical, but in some circumstances it's not even
correct, because the doubled slash changes the interpretation of the
path completely by introducing UNC or URL semantics.
Hello Mark,
Thank you for having explicated the concept of canonic paths, which of
course has underlied this thread.
Basically, the discussion quickly went about the mapping between posix
paths and mac-style paths as provided by AppleScript coercions.
That is, AppleScript may be seen as providing at least one production
rule of this kind:
convert(<posix path>) --> <mac-style path>
for example:
(POSIX file "<posix path>") as text
Such a rule has to take into account dissimilar paradigms.
For example, a mounted disk volume may appear either as a path to a
directory within the system file tree or as a distinct tree.
Or, an item (e.g., a bundle) may appear either as a directory or as a
file.
But such a rule should also be consistent.
For example, a consistency requirement could be: when applied on a
given path, the rule should always yield the same result.
Another requirement could be: if provided with a canonical posix path,
the rule should yield a mac-style path that is canonical as well.
Now, as it has been seen, perhaps a more realistic requirement would
be: the strings produced by the rule must make sense and be
predictable thanks to an explicit algorithm and the enumeration of its
special cases...
To be honest, I'm unable to decide which rules exactly should be
viewed as the correct ones.
Because of the use of POSIX file "<posix path>".
Since "POSIX file" allows to build a file reference from a posix path,
the targeted item may or may not exist. The coercion of such an object
to text should thus not depend on the existence of the target item. If
provided with a canonical unix path, ((POSIX file "<posix path>") as
text) thus shouldn't append a trailing column on the mac-style path,
as it is indeed the case for:
(POSIX file "/System") as text
--> "BootDisk:System"
After all, my intent may be to refer to a potential file named
"System" at the root, even if there is already a directory bearing
that name.
Then comes the discussion about the paths for mounted volumes, and so
on.
On the other hand, it may be that a mechanical adoption of Yvan's rule
is at work: "if the unix path syntactically ends with a slash, then
the corresponding mac-style path has an ending semicolon". In which
case it would be needed to explicitly state the fact, and to specify
whether this is an IF or an IIF rule, along with its possible
exceptions.
But the question was about disk volumes. Chris said that HFS paths to
volumes have to have a trailing colon, and Axel pointed out that
(POSIX file "/Volumes/Foo" as text) yields bare "Foo" without the
trailing colon, which seems to disprove that statement. Although that
could just be a bug in AppleScript's stringification. I note that
(POSIX file "/Volumes/Foo" as file as text) does put the trailing
colon in.
The same way it will add a trailing semicolon for any existing
directory.
It seems that the coercion of a (POSIX file "<unix path>") to a file
to a text involves some check for the existence of the item: if a
directory, let's add a semicolon...
And so we are back to another longstanding question: (POSIX file
"<unix path>") yields an object of class "furl", while ((POSIX file
"<unix path>") as file) is a "file specification"...
Axel _______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users
This email sent to email@hidden