Detlef Kahner I will use your approach this, Thank you for the tip!
Tanks Norman Palardy for your help !
Aircraft carriers to you too! 
I’m running various CL utilities in my applications. I can be calling the shell script from XOJO code or from an Applescript, depending on the situation. This has all worked just fine since sandboxing was introduced. Now, if I try to execute a shell in Application Support, it’s definitely NOT working. Something as simple as creating a folder, to running tools like sips and textutil don’t work.
Creating the folder works if I make it with XOJO code, just not if it’s created with the shell.
Erm, gestalt has been depreciated… There are better ways of getting the version number.
deprecated but not removed - yet
With what I can decipher, the alternatives are:
NSAppKitVersionNumber (which is a framework constant) and returns the build number of the AppKit framework.
[NSProcessInfo operatingSystemVersionString] which returns a human readable string (Apple advise not parsing this to get to the version number).
If you’re using it to figure out if a function exists:
NSClassFromString( className ) will return nil if the class doesn’t exist (NSSharingServices on 10.7).
[NSObject repondsToSelector:selectorName] will see is the selector exists, however I have found that sometimes it returns false when the function is there.
Well, my bug has been closed as being a duplicate of 18004631, to which I cannot see! Downloading the new DP and seeing if it’s been fixed or not.
Okay - so no, DP6 didn’t fix it… There’s hope for DP7? And as we’re talking about gestalt earlier, I noticed this message in the console of DP6.
Backup To Go.debug[520]: WARNING: The Gestalt selector gestaltSystemVersion is returning 10.9.0 instead of 10.10.0. Use NSProcessInfo's operatingSystemVersion property to get correct system version number.
Call location:
Backup To Go.debug[520]: 0 CarbonCore 0x9b287c1f ___Gestalt_SystemVersion_block_invoke + 135
Backup To Go.debug[520]: 1 libdispatch.dylib 0x92a2e280 _dispatch_client_callout + 50
Backup To Go.debug[520]: 2 libdispatch.dylib 0x92a2e205 dispatch_once_f + 251
Backup To Go.debug[520]: 3 libdispatch.dylib 0x92a2f227 dispatch_once + 31
Backup To Go.debug[520]: 4 CarbonCore 0x9b21a41c _Gestalt_SystemVersion + 1050
Backup To Go.debug[520]: 5 CarbonCore 0x9b219fcd Gestalt + 150
Backup To Go.debug[520]: 6 XojoFramework 0x009007ca systemGestalt + 122
Which suggests to me that Gestalt my be returning the incorrect value, as it claims to be return 10.9 instead of 10.10.
Yes, if you must use gestalt, don’t use it with gestaltSystemVersion. Use gestaltSystemVersionMajor, gestaltSystemVersionMinor, and gestaltSystemVersionBugFix.
The suggested replacement is only available on 10.10 or iOS 8 
At least it returns a nice structure :)[quote=122393:@Joe Ranieri]Yes, if you must use gestalt, don’t use it with gestaltSystemVersion. Use gestaltSystemVersionMajor, gestaltSystemVersionMinor, and gestaltSystemVersionBugFix.[/quote]
I just found a place where I was using the dirty deed… Now replaced. Hopefully I won’t get that console message any more… Although it does say the XojoFramework…
It’s your program calling System.Gestalt, which calls into XojoFramework, which calls into the system gestalt function.
Gotcha! Should be all good in the world of Gestalt now 
DP6 didn’t solve my sandbox issue. What’s interesting is that a couple of my apps don’t use the Application Support/MyApp folder (which I’m using as a temp folder of sorts) and just run their shell commands directly to the open/save location that I have as a standard sandbox exception. In this cases, the shell works fine inside a sandboxed app. Perhaps my solution is to create a invisible folder in this location to use as a temp, then delete it on the way out?
Why not use a folder within Temp ?
Is that available without entitlement to a Sandboxed app?
My memory of was that only the Application Support/MyAppName was available to a Sandboxed app without entitlement,
[quote=122585:@Niles Mitchell]Is that available without entitlement to a Sandboxed app?
My memory of was that only the Application Support/MyAppName was available to a Sandboxed app without entitlement,[/quote]
I use SpecialFolder.Temporary very intensively in one of my MAS apps with no special entitlement.
I’m not on a Mac right now…what’s the POSIX path? ~/temp?
I have always used it as folderitem = SpecialFolder.Temporary
According to the LR http://documentation.xojo.com/index.php/SpecialFolder it varies around this for unsandboxed
private/var/folders/gp/wtyftxf176l22dz9qlwqw5v40000gn/T/TemporaryItems (varies)
I just verified with a sandboxed app :
/private/var/folders/sw/q9mqn7gd0jbg24kmdzxnv5qw0000gn/T/com.myapp.dropz/TemporaryItemsAs you see it is not a fixed path.
[quote=122593:@Michel Bujardet]I have always used it as folderitem = SpecialFolder.Temporary
According to the LR http://documentation.xojo.com/index.php/SpecialFolder it varies around this for unsandboxed
private/var/folders/gp/wtyftxf176l22dz9qlwqw5v40000gn/T/TemporaryItems (varies)
I just verified with a sandboxed app :
/private/var/folders/sw/q9mqn7gd0jbg24kmdzxnv5qw0000gn/T/com.myapp.dropz/TemporaryItemsAs you see it is not a fixed path.[/quote]
There has to be a POSIX equivalent that always resolves to it. SpecialFolder.Temporary would tie into that equivalent.
I can’t use SpecialFolder.Temporary in an Applescript or a shell script, which one of my apps relies heavily on.