Having had this problem and found it tough to solve, I though others might like to read John Gruber’s take on it: “Wrong Folder Returned by ˜path to’ Command in System Events Tell Blocks”
Thanks – that’s gotten me before but I never understood it.
I’m not sure I agree with Mr. Gruber’s evaluation of the subject. Granted, I do see his point about how sometimes it is nice to clean up code by sticking associated commands and lines together… but that is the limit to which I agree.
You wouldn’t try to call finder commands from within a system events block, why would you assume that a standard additions command would work any differently? There are many, MANY commands which will throw errors when included in tell blocks unnecessarily. This is not a stylistic issue, it is one of computer logic, and should be evaluated as such. There have been countless threads on this forum where users have run into problems with their code, and the one simple remedy was that they needed to move one line from within a tell block out into their main script flow. It is actually BAD programming practice to write your code in such a manner that convenience is your primary logic. Chances are your code will be faster and more predictable, and your brain will get sharper, when you write code as if you were doing so to please the computer… not yourself. I personally do not put anything into a tell block that does not need to go there. Tell blocks are not complicated structures… i.e. they don’t “return” values like subroutines, and they don’t require local declarations of their values like script objects or subroutines. The ‘path to’ command does not NEED to be executed in the tell block for the rest of the code to use the variable it sets. Any speed or processing or convenience advantage you hope to gain by placing code in the wrong place in your scripts will ultimately always be offset by extra troubleshooting, lack of performance, and frustration.
To create code that is efficient, safe, and appealing is always a challenge. By always considering every line of code you put in… BEFORE you put it in… you eliminate many obstacles and errors before they ever happen. Because the ‘path to’ command is provided by the standardadditions osax, and not by system events, I don’t see why you would even want to try putting it there. Regardless of how you cut it, there are still the same exact number of lines of code, and pissing about it because it doesn’t look pretty seems like a waste of a web page. I’m a bit surprised that it does work properly inside the finder block, and even more surprised that it doesn’t just throw an error. Arguing that this is a “bug” is really just a smokescreen for either not fully understanding applescript, or just being lazy. When I can’t figure out WHY some things are as they are, it is really easy to get in the habit of blaming the system for having rules, rather than blaming myself for not understanding them.
j
Starting with John Gruber’s first step and before delving into Finder and System Events, the error he reports happens when the script tries to get every item of an alias. An item is an element of a list. Every is an element specifier, so wouldn’t it only be used with lists?
This return a list with one element, which is what one would expect, without introducing Finder or System Events scripting into the mix.
set p to (path to application support from user domain) as list
set myList to every item of p
If the point of the script is to get a listing of the contents of the application support folder (any of them) then it can be done by using list folder from Standard Additions.
set p to path to application support from user domain
set my_List to list folder p
Seems like he would like an item to be something it isn’t.
Craig
Wow, Jobu, I didn’t mean to start a war but I must quibble a bit with “Arguing that this is a “bug” is really just a smokescreen for either not fully understanding applescript, or just being lazy.” Rather strong stuff.
AppleScript is supposed to be a natural language-like programming language for the rest of us and so large numbers of wanna-be scripters do the best they can without being lazy or fully understanding the structure of AppleScript. Many texts on AppleScript (and I’ve read a bunch of them) explain how an instruction not in the vocabulary of an application should pass up to AppleScript for interpretation. When it doesn’t seem to do so automagically (because lots of readers here can’t always tell when it will or won’t), folks get stuck or where appropriate use “my”. The problem with asking System Events to deal with a path is that path is a word in the Folder Actions suite of its dictionary that is not consistent with the Scripting Additions version.
I agree with suthercd, but I think that Gruber’s beef had more to do with not being warned in any way than with the inconsistent result.
I sorta agree with jobu. There’s always been a danger of name space clashes with OSAXen and it’s good practice not to put stuff in ‘tell’ blocks that needn’t be there and not to nest tell blocks from different applications. Before OS X, it was considered fatal to put certain ‘path to’ calls in Finder tell blocks. Now it’s System Events, which has not only five different ‘path’ properties, but also ‘user’ and ‘user domain’ elements and properties. Presumably the confusion’s happening at the compilation stage.
Since the command actually works in the ‘tell’ block, albeit incorrectly, I’d guess that it’s the ‘user domain’ keyword that’s being wrongly compiled. In fact it is. Look:
set fred to user domain -- compiled outside block
tell application "System Events"
path to application support from fred
--> alias "G5 HD:Users:nigelgarvey:Library:Application Support:"
-- But:
path to application support from 7 -- rubbish parameter
--> alias "G5 HD:Library:Application Support:"
end tell
It’s weird that a variable can be set to a compiled keyword ” and probably a bug that ‘path to’ doesn’t complain about bad ‘from’ parameters. It simply pretends they’re not there… 
Agree about “bad practice” and “good practice”, and I’ve learned the hard way as I pointed out in the opening to this thread.
Again, I see your point, but agree with Gruber that ideally, when in doubt, there should be some sort of message from the compiler.
Now you’ve reached the nub: It simply pretends they’re not there…. I call that a bug even as I agree with Jobu’s notion of “bad practice”. What I disagreed with was the harshness with which he branded newbies as Lazy or, in essence, too dumb to appreciate all the nuances of the structure of AppleScript. Been there, done that, own the tee shirt myself.
Adam, I certainly meant no disrespect. There are SO many things I do not know about applescript that I’ll probably always consider myself a newbie. I realize that my response could have easily been taken in the wrong light, but I assure you that I intended no harm. My comments and questions were not directed at you, and were not meant to judge you or your abilities. My insights were merely my opinions about scripting logic, and my questions were purely rhetorical. I was not challenging you, and was only responding with comments which I felt brought a new angle to Gruber’s comments. I hoped that by sharing my experience, perhaps others… including newbies and, uh, ‘oldbies’… would perhaps see that when following the rules that things usually work out right in the end. I didn’t ever suggest that everyone should already know everything. What I meant to convey, is that knowledge ultimately comes from experience (as you’ve found).
I myself have been beating my head trying to get my Xcode plugin project to do something extremely simple. In the end, the solution was right in front of me, and I’m quite embarrassed that it took me so long to find out that one line of solid code could replace the 20 or so INSANE lines that I was trying to use before. What I’m trying to get at, is not that YOU are an idiot… or that ALL newcomers to applescript should just pack up and leave… but that sometimes things do not exist just to piss us off.
I do still feel that stylistically it is better to “think like the computer” (however cliche that may sound) and do things as the computer would best like them. Yes, applescript is designed for “the masses” or the “common man”… but sometimes Joe Schmoe can’t figure it out and the mud starts flying about how things are not as they should be or, “why can’t applescript be like ?”. Regardless of whether applescript is supposed to be a “natural language-like programming language”, it is nonetheless a programming language. In finding a solution to the problem by writing solid and stylistically correct code, I think my points about the benefits of writing good code have been validated. And, the only way to get to that point is to go through the trials of failing and then succeeding at it. No one just jumps into speaking another language without some learning curve.
As far as the unexpected behavior of the command as Nigel describes, although inconvienient, it is as I would expect… personally. The “path to application support from 7” example, although not part of the original comments, should probably return an error. The parameter is optional, though… and the command does default to the local domain… so having it ignore the bogus parameter seems appropriate. A syntax error would probably be more reasonable, I agree. With regards to the original post, I still think it is acting as it should. The syntax is correct… as far as the compiler and the computer can tell. What is confusing, is that all of the syntax compiles, but because some of the references are handled by system events and the rest are handled by the standard additions, a valid reference is made, but not always to the desired item. Some other osax references are handled, like ‘fonts’, or ‘keychain folder’… while others are not. The key though, is to remember that you are EXPLICITLY asking ‘system events’ what it thinks, when it IS NOT the authority on the subject. By simply moving the code out of the block… POOF!.. it does work. No automagic involved. As we all learn to write better and better code, we learn to see the commands and variables as DATA, not as a friendly chat with Ma and Pa on the porch. Yes it is a language… and yes it’s supposed to be simple… but there are still rules. Rules, that despite how you’d LIKE them to work, actually work a different way because that’s just how they must.
To eliminate some confusion, yes, some might call it a bug. It is a unique situation where the osax is trying it’s hardest to keep a bad bit of code from being entirely disfunctional. It does it’s default action and throws out someting you would not expect… but it’s still a valid reference and what is intended by the command’s guidelines.
Don’t take anything I say too seriously. I think every obstacle should be approached as a learning experience… not a burden. We’ve all had an opportunity to see things in a whole new way, and I know I’ll be paying EVEN MORE attention now to what I put in my tell bocks.
Now, back to my head banging…
jed
And in case there’s any doubt, that was my intention too. In fact, I’d like to thank NovaScotian for bringing up the subject, as I hadn’t encountered this particular System Events effect before and I’m sure many others will benefit from being forewarned too.
I certainly wouldn’t deride anyone who was flummoxed by an unanticipated script problem (unless I was in a odd mood, of course 
); but people who publish articles claiming that something’s a bug because it doesn’t let them write scripts in a certain way is perhaps setting themselves up for a comment like jobu’s.
The compiler itself doesn’t actually have a problem with the situation. It doesn’t know what the lines in a script mean. It’s only concerned that the grammar’s correct in the given context(s). ‘path to’ doesn’t make grammatical sense in the System Events context but is then recognised as a command from the StandardAdditions. There’s a ‘from’ that doesn’t make sense in System Events but is a keyword for an optional parameter of ‘path to’. This parameter requires a value. The next thing in the line is ‘user’, a System Events keyword, but then you’re left with ‘domain’. However, ‘user domain’ is also a System Events keyword and so the token for System Events’ version of that is compiled into the script. Grammar is satisfied and the compiler isn’t obliged to check that ‘user domain’ is defined in any other context.
The problem comes when the script runs: ‘path to’ doesn’t recognise the value it’s been given for its optional ‘from’ parameter. I’d personally prefer it to throw an error to highlight the problem ” although the message would probably be something unhelpful like “Can’t get path to application support from user domain.” But it just ignores the ‘from’ parameter altogether and uses the default domain for the specified target. This seems less than ideal ” though I wouldn’t like to write an article about it.
Great explanation! You wouldn’t need too much more than this in your article.
gl,
… and I think this is a neat way to put it too, jobu. No offense taken.
This article’s currently being discussed on the AS-Users mailing list: http://lists.apple.com/archives/applescript-users/2005/Sep/index.html (“AppleScript a miserable and utter failure”) ” if anyone wants to eavesdrop.