Re: path to as string
Re: path to as string
- Subject: Re: path to as string
- From: Shane Stanley <email@hidden>
- Date: Fri, 01 Jul 2005 12:01:15 +1000
- Thread-topic: path to as string
On 1/7/05 10:53 AM, "has" <email@hidden> wrote:
> Understand, HFS paths have a fundamental flaw in that they cannot distinguish
> between different disks with the same name. So I'm not suggesting folk prefer
> POSIX paths simply for the fun of it. Nor am I saying folk _never_ use HFS
> paths when they've no other choice. What they do need to know is that Unicode
> POSIX paths are good and HFS strings are not good, so it's best to use the
> former and avoid the latter whenever there's a choice.
But you've left out the choice of Unicode HFS paths.
> The only app I know of that has issues with HFS vs POSIX paths is Finder
You need to get out and mix more.
> Pretty much every other scriptable application and osax should not, and do
> not, use path strings at all. I'm sure we all remember the stushie circa OS
> 10.2 that certain Cocoa apps caused by requiring [POSIX] path strings. Since
> then, Apple have stated quite clearly that applications should use file
> objects (alias, POSIX file, etc.), not path strings.
That's great, but let's get back to the real world. Script Editor returns
what for the path of a document? What do apps like Word and Excel require to
open a file? There's little consistency.
> Look, I'm against ASers directly mucking about with file paths as a matter of
> course, period. It only creates extra work and more opportunity for mistakes.
> There should be a set of standard library commands that provides all the
> day-to-day functionality needed to split, join and otherwise wrangle path
> strings in complete safety.
Meanwhile back here on planet Earth we have to do these things regularly,
and in many cases they strike me as easier to do with HFS paths.
> But AppleScript doesn't have a standard library
> worth a damn, and it's nigh well impossible to get ASers to accept a
> third-party one, so the point is somewhat moot.
So if that point is moot, then the point of choosing HFS paths over POSIX
paths for, among other things, ease of manipulation, is valid.
> So as long as they're going to
> mangle them directly, they should at least be shown how to do it as safely as
> possible, which means using POSIX paths and Unicode text, not HFS paths and
> strings.
Who said "strings"? I'm talking HFS paths in Unicode. And you just said that
POSIX paths don't always work properly, so what is your definition of
"safely as possible"? On a practical note, if I have the choice of a system
that will fail if two disks are the same name, or a system that might fail
with non-English characters, I know which is easiest to deal with.
> Again, the SIG is quite clear that they should NOT be dealing in path strings,
> either POSIX or HFS. And any app that barfs on a 'POSIX file' object deserves
> a solid smack in the head because that's just sloppy implementation.
OK, so I 'tell app "Whatever" to smack head'. Now I have to do some work
with it. Sadly, I don't feel much better.
> You can deal with its botched 'string' implementation, or its botched 'Unicode
> text' implementation. You can deal with its botched HFS path support, or you
> can deal with its botched POSIX path support.
But surely the decision should be based on practicalities rather than vague
references to things being "kinda legacy".
--
Shane Stanley <email@hidden>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Applescript-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden