The choose folder command’s dictionary lists the purpose of the command as:
Choose a folder on a disk or server
and the return value of the command as:
alias: the chosen folder
And here’s Wikipedia’s definition of a software bug:
A software bug is an error, flaw, failure or fault in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways. (my underlines)
Does that sway your thinking (even a little 
)?
Not particularly. The clear implication is that you use it correctly, with the correct parameters. That’s the contract.
If you pass a file rather than a folder, it’s a bug in your code. It would be ideal if the command cleaned up for you, or perhaps threw an error, or ignored the parameter – but to suggest it has an obligation to is, I think, going too far. It doesn’t say it will, and it doesn’t.
It’s a testament to my G5, which I bought only a day or two before Apple announced it was switching to Intel processors :mad: and which has proved the most reliable and longest-lived of my computers so far — if not particularly useful in recent years.
It’s AppleScript Engineering you have to convince.
I understand much better the point you are making. I find these kinds of discussions to be a purifying fire that forces clarity of thought and expression. In the current case, it would be interesting to learn more about the topics of developer obligation, undocumented behavior, and bugs, but that’s getting too far off course.
That is where my thoughts were going. It seems that it must come down to the AppleScript engineers either wanting this behavior, in which case it would be nice if it were documented, or not wanting this behavior, in which case they should remove it. I’ll file a “bug” report (in quotes; it’s the only venue I’m aware of for submitting this!) but state the matter in these terms, then see what comes of it.
10.5.8 file type determination was done by Carbon’s (OSType) codes. Modern OS X systems favors the much more flawed UTI schemes. IIRC user interaction of the StandardAddition was all Carbon till at least Snow Leopard. That would explain the difference in behavior.
That was my suspicion, too. Which means it would have been using Navigation Services.
Satimage.osax still has Navigation Services dialog commands, including navchoose folder. Of course it won’t run in 64-bit mode. But if you run it from a 32-bit host, like this:
navchoose folder starting at alias "Macintosh HD:Users:shane:Desktop:Dictionary.html"
you will still see the behavior Nigel noted.
I submitted the matter to Apple’s Bug Reporter under the title Unexpected behavior of AppleScript’s “choose folder” command and referenced the fact that the expected behavior used to be present when file typing was done with Carbon’s OSType codes.
Let’s see if a small miracle comes of this.
Incidentally, I would find it useful if the choose folder command reverted to its prior behavior of permitting its default location parameter to be set to a file alias and then opening to the containing folder of that file without any items pre-selected. That would eliminate the unintended consequence of getting an alias to a file if the user presses the “Choose” button without selecting any other items. Currently, the programmer must perform the extra step of extracting the file’s containing folder first and then using the extracted folder alias as the value of the default location parameter in order to achieve this desirable behavior.
I wasn’t explaining or confirming a bug, just explaining difference in behavior between OS Base SDKs. Once you understand the difference Carbon and Cocoa, it becomes clear why it behaves differently.
choose folder command is not a special command in AppleScript, or a command specially written for AppleScript. In the early days NavChooseFolder() was called from the Carbon framework who had similar arguments as the choose folder in AppleScript. Choose folder command was nothing more than an translation between AppleScript and Carbon. A lot of these commands was nothing more than a 1:1 translation from the Carbon functions/methods. However in Cocoa these Nav… functions doesn’t exist; so they’re replicated as close as possible but can’t be an exact replica as choose folder has proven.
While difference in behavior I agree with Shane, this isn’t a bug. It’s an undocumented and unannounced transition from Carbon to Cocoa which make choose folder behave differently. It’s not a bug because every part is intentional and nothing is unexpected (from AppleScript Engineers point of view).
However the choose folder command is implemented since the transition to Cocoa, the current behavior still seems odd. The command simply should not allow a non-folder to be set as the default selection, nor should it return a reference to a non-folder to the calling program.
Rather than confine themselves to a 1:1 translation of whatever Cocoa technology they are currently using behind the scenes, wouldn’t it be an almost trivial task for the AppleScript engineers to modify the implementation such that the command allows only folders to be pre-selected and only folders to be returned to the calling program? Choosing and returning folders is, after all, the very reason for the command’s existence.
P.S. I should have begun by saying that I completely understand the point you and Shane have been making, that the current behavior of the command is its expected behavior. The report I submitted simply makes the request that they consider modifying the implementation so that its behavior reverts to that of the old choose folder command, which I find not only more intuitive but also more useful for the reason I described in the last paragraph of my previous post.
It won’t – unless you ask it too.
The old joke…
Patient: Doctor, it hurts when I do this.
Doctor: Then don’t do that.
That’s all I’m asking.
Don’t forget the showing package contents parameter which makes packages behave like normal folders and allows you to choose packages as normal folders.
Thank you for pointing that out. I hadn’t looked at the role of the showing package contents parameter in all of this. But its behavior highlights even more, at least from my perspective, the nonintuitive nature of the choose folder command’s current behavior.
With the showing package contents parameter set to true and the default location parameter set to a package (in this case, the TextEdit.app bundle), the choose folder window opens to the contents of the package, as expected:
set texteditBundleAlias to ((path to applications folder as text) & "TextEdit.app") as alias
choose folder default location texteditBundleAlias with showing package contents
--> Opens to the contents of the TextEdit.app package, as expected
However, with the showing package contents parameter set to false and the default location parameter set to the TextEdit.app bundle, the choose folder window still opens to the contents of the TextEdit.app bundle, rather odd behavior given that the expression without showing package contents appears explicitly in the command (and again reflecting the seeming absence of filtering of the default location parameter value in the current implementation of the command):
set texteditBundleAlias to ((path to applications folder as text) & "TextEdit.app") as alias
choose folder default location texteditBundleAlias without showing package contents
--> Opens to the contents of the TextEdit.app package, even though the command reads: "without showing package contents"
I wonder if I might impose on Nigel to travel back in his time machine and see how the command behaved back in the NavChooseFolder days with the showing package contents parameter set to false. I suspect (and would hope) that the window would treat the TextEdit.app bundle as a non-folder and instead open to the contents of its containing folder, namely the Applications folder.
Just for info, it behaves the same under 10.13.4.
Yvan KOENIG running High Sierra 10.13.4 in French (VALLAURIS, France) jeudi 31 mai 2018 21:04:35
You’re missing DJ’s point: the behavior is set by the underlying Cocoa framework. The choose folder command is just AppleScript giving access to the NSOpenPanel class.
If you want to log a bug/request on the behavior with bundles, then at least log it where it belongs: the NSOpenPanel class.
It’s hard enough to get even serious AppleScript bugs fixed these days, and asking for precious time to be spent on trivia risks being counter-productive, IMO.
Couldn’t have said it better myself
That’s exactly what I meant. The behavior has always been set by the underlying framework/API and was never defined by AppleScript itself. Supporting the behavior of an API that’s been deprecated since the 32-bit to 64-bit transition of Mac OS X and denying the behavior of currently supported API is what I would call nonintuitive.
Somewhere in the future the Carbon API will no longer ship with Mac OS X (by default). When that day happens and bmose request would be granted, choose folder’s behavior follows an phantom.
I would suggest the same thing. AppleScript doesn’t define the behavior of choose folder and bmose doesn’t like how NSOpenPanel works compared to NavChooseFolder. Why should this problem be addressed at OSAX-level while knowing that every application who let the end user choose an folder using NSOpenPanel have the same potential “bug”?
@bmose: The reason why I’m so stubborn on this subject is only because I prefer an OS where open and save windows behave exactly the same in all applications with no exceptions. I don’t see any reason why AppleScriptObjC’s NSOpenPanel should behave differently from choose folder while both solutions eventually uses the same NSOpenPanel.
Shane and DJ, forget it, it’s too late to apologize! (Sorry, just kidding. I couldn’t resist an old Bennie Hill joke. Bennie said that after he had bungled something up badly but, because of a language barrier, was clueless as to his own culpability. 
)
I’ll just go back to grinding it out: #1 extract a file’s containing folder with System Events, Finder, Cocoa, or the shell → #2 execute the choose folder command with the default location parameter set to that value → repeat at #1 → …
An alternative, I suppose, would be to write one’s own “choose folder” or NSOpenPanel wrapper that restores the old behavior. 
I can understand that argument.
I received the following reply from the Apple Bug Reporter:
I don’t have macOS 10.14 beta installed and was wondering if someone who does have it installed might be able to test this out.
To test the matter, one would issue a choose folder command with the default location set to the alias of an existing file, not a folder. If the issue has indeed been resolved, the “choose” dialog window should open to the file’s containing folder without the file highlighted as the default selection. The following command would work:
choose folder default location alias ((path to library folder from user domain as text) & "Safari:Bookmarks.plist")
The “choose” dialog window should open to the user library’s Safari folder, and the Bookmarks.plist file should not be selected if the issue is resolved.
Just to close the loop now that macOS 10.14 is out, Apple did indeed restore the choose folder command’s former behavior. It now opens to the default location’s containing folder without pre-selecting the file when the default location is set to the alias of a file. To demonstrate, save a file (not a folder) on the desktop, for example, an AppleScript script named SampleScript.scpt. Then run the following command:
choose folder default location (((path to desktop as text) & "SampleScript.scpt") as alias)
The choose folder dialog window will open to the desktop folder without SampleScript.scpt being pre-selected.
I was hoping the fix would have been implemented at the level of Cocoa’s NSOpenPanel. I tested NSOpenPanel’s behavior using the script Shane Stanley posted earlier in this thread. Unfortunately, the dialog window still opens with the file pre-selected even though NSOpenPanel’s setCanChooseFiles: method is set to false.