It would appear that Gatekeeper in macOS Sierra is a bit pickier. At any rate, it is causing a small utility I made some years ago to throw a rather annoying error.
As I haven't yet had the time to dig into the under-the-hood changes in Sierra, I'm not sure how to fix the error. Does anyone have experience dealing with errors relating to AppTranslocation and fixing them?
Code and error follow:
Code:
tell application "Finder"
set currentDir to POSIX path of ((container of (path to me)) as text)
end tell
set currentDir to quoted form of currentDir
set lib80211 to quoted form of "AirPort Utility 5.6.1 Launcher.app/Contents/Resources/Apple80211.framework/Versions/A/Apple80211"
do shell script "export DYLD_INSERT_LIBRARIES=" & currentDir & lib80211 & "
cd " & currentDir & "AirPort\\ Utility\\ 5.6.1.app/Contents/MacOS
./AirPort\\ Utility"
Error:
sh: line 1: cd: /private/var/folders/t4/7k5z832d2tjd4xpzvvq43n4m0000gn/T/AppTranslocation/23AF67A4-3DF7-4982-A1A3-B019CDACB4C2/dAirPort Utility 5.6.1.app/Contents/MacOS: No such file or directory
sh: line 2: ./AirPort Utility: No such file or directory (127)
Well, after a fairly significant amount of trial and error (and a bit of reading about how AppTranslocation works in macOS 10.12 Sierra), I've discovered a fix.
In essence, you have to open the *.dmg and then move the contents to some other folder in Finder. The catch: If you move both simultaneously, AppTranslocation may 'tag' them (seemingly permanently) and continue to run every time you try to launch either *.app); this seems like a bug, and I intend to report it to Apple.
The Solution
Re-download the *.dmg (as others have stated) and move the two files it contains one at a time into a folder (preferably Utilities, but it's up to you where you want them to reside). Once you've done this, run the Launcher and everything should work as before.
You have to download once again Airport Utility Launcher from the dev website, because when you install macOS Sierra it erase the Airport Utility 5.6.1. that's why you have to download the whole folder from the website :http://zcs.zyniker.org/airport-utility-v5-6-1/
Hope it helps.
Related
So here's a peculiar situation. I created an AppleScript application that relies on the path to me command. After saving as AppleScript Application it runs perfectly. However, if you archive/zip the file, then unzip and run again after downloading/emailing or on another computer, the path to me is incorrect.
For example, I created a super simple app to test this:
set myPath to (path to me as text)
display dialog "myPath: " & myPath
Save the application and run it from the Finder by double clicking it.
Mine reports correctly: myPath: Sierra:Users:joshbooth:Desktop:Test.app:
Zip/Unzip the file on my other laptop and run again.
The result is myPath: 429EF755-2646-4249-A428-666D454E9DAD:d:Test.app:
Option + click and drag to create a new copy in the same directory then run again:
result: myPath: Macintosh HD:Users:joshbooth:Downloads:Test 2.app:
Any ideas what is happening or how to prevent it?
I've no real "answer", but my info is too big for comments (and no one else has chimed in)...
While there may be other cases, at least one cause is a downloaded zip being marked "quarantined" which results in OS X expanding it into a temp "/private/var/folders" location (with the complex folder name you see, as well as the expanded item being quarantined and actually on a read only file system).
So, it is the "download" biting us, which we can see in the "com.apple.quarantine" attribute of the app, and zip, in a terminal window with "xattr -l /Users/johndoe/Downloads/Test.app" (like "com.apple.quarantine: 0083;5f20ce0e;Safari;BFABF751-2ACD-4B6F-9952-9A87D45AC9D4"), and remove it with "xattr -d com.apple.quarantine /Users/johndoe/Downloads/test.app".
Getting (POSIX path of (path to me as string)) within the expanded app would have shown something like /private/var/folders/lh/9hl01d1n2knckzj0bxdb22lr0000gn/T/AppTranslocation/429EF755-2646-4249-A428-666D454E9DAD/d/Test.app before removing the quarantine flag.
Unfortunately, given the temp path is locked, the app itself can't remove the flag with "xattr -d com.apple.quarantine /private/var/folders...", getting "xattr: [Errno 30] Read-only file system", so idea what we can do with this info, but these are my findings.
One good note: moving or copying the expanded app to another folder leaves the quarantine flag set, but updates the "path to me" resolution, which is a bit inconsistent, and confusing, by OS X in my opinion (debatably defeating this quarantine flag pattern if it was intentional), but a useful workaround.
After Xcode update to version 8. The very useful Alcatraz PlugIn Manager is locked out and superb utilities like clang-format, or highlight selected word occurrences, or resize the font by use of a shortcut are gone.
How can I reenable clang-format to format my current source code file on save with a template .clang-format in any parent directory of the source file?
You could create a shell script that is added to Xcode 8 as a behavior: Xcode > Behaviors > +(to create new one) > Run script: (select file here), add shortcut like Cmd+Shift+S.
The script asks Xcode to save the current document. Then it extracts its filepath and calls clang-format to format that file in-place. Clang-format has to be available e.g. by using brew as the package manager to download it and having its path published for command line access. As usual the style guide used by clang-format must have the name .clang-format and must be in any parent folder of the source file.
Here is the script:
#!/bin/bash
CDP=$(osascript -e '
tell application "Xcode"
activate
tell application "System Events" to keystroke "s" using {command down}
--wait for Xcode to remove edited flag from filename
delay 0.3
set last_word_in_main_window to (word -1 of (get name of window 1))
set current_document to document 1 whose name ends with last_word_in_main_window
set current_document_path to path of current_document
--CDP is assigned last set value: current_document_path
end tell ')
LOGPATH=$(dirname "$0")
LOGNAME=formatWithClangLog.txt
echo "Filepath: ${CDP}" > ${LOGPATH}/${LOGNAME}
sleep 0.6 ### during save Xcode stops listening for file changes
/usr/local/bin/clang-format -style=file -i -sort-includes ${CDP} >> ${LOGPATH}/${LOGNAME} 2>&1
# EOF
Please exchange the path /usr/local/bin to the one where your clang-format executable resides.
Happy coding!
The mapbox/XcodeClangFormat extension looks like a promising way to get clang format working with Xcode8.
Due to the limitations of source editor extensions, unfortunately you can only specify one .clang-format file for all your projects. "Format on save" also is not available.
Found a viable solution in this blog - code-beautifier-in-xcode
Basically, we can have clang-format running as a service by automator and invoke it through Xcode whenever we need to format the code. Refer the blog for more details.
Unfortunately your little script often does not update the formatted file in Xcode because it stops listening to file updates when saving. Increasing the sleep durations in the script does not make it more reliable and introduces a lot of waiting time for the common file-save & file-format action.
What I did in your situation was to get my mac backup and restore macOS and Xcode to the last version where all the productivity plugins from Alcatraz work fine again. This boosted my productivity.
It looks like Alcatraz plug-ins get be back to work in Xcode 8+ when unsigning them. Because I am not in the situation to try that, I can only point you to that resource:
Examine the header Installation on that github page ClangFormat-Xcode.
I went to run an old script and it broke after the 10.9 update. I used to move files with system events with the following code.
set Somefilepath to "Design_005_HD:Users:Design_005:Desktop:Start:TextFile.txt"
set somefolderpath to "Design_005_HD:Users:Design_005:Desktop:End:"
tell application "System Events"
move file (Somefilepath) to folder (somefolderpath)
end tell
Now it gives me the following error.
error "System Events got an error: Can’t make file
\"Design_005_HD:Users:Design_005:Desktop:Start:TextFile.txt\" into
type integer." number -1700 from file
"Design_005_HD:Users:Design_005:Desktop:Start:TextFile.txt" to integer
I know I can swap it out and use finder but I rather not use it. What changed that is no longer works?
Update 4/2/14
I have tried this in every way of giving the file/folder location to system events and it doesn't work. I am glad it is just not me who cannot get it to work. I will update this post if I find an answer or a working update is made.
Update 4/3/14
It seems this is just a bug that system events can't move files. I have reported it here http://bugreport.apple.com/ and everyone else should too.
Please do not take my code to heart, it is just where things ended up when I couldn't get it to work. I have working code for 10.8.5 and it is what is shown above minus the folder tag in the system events tell block. No idea why it works with out the folder tag but it does. Tested on multiple comps. If it isn't broken don't fuss over it. Noted it and moved on.
Update 10/20/14
For anyone interested. I have received an e-mail stating my ticket has been closed/resolved. So mavericks will for ever be broken but there might be light for Yosemite when it comes out.
In general, Applescript works with colon delimited paths (:) not slash delimited paths (/). I say in general because some applications will work with slashes but all programs will work with colons. For an example of what the colon paths look like try this code and look at the result...
set colonPath to (path to desktop as text) & "untitled folder 2:"
So first I would convert your slashes to the colon style.
Also to applescript these are just strings not paths. To make applescript understand they are paths we can do a few things. First you can add the words file or folder in front of them as appropriate. I notice in your code you are using "file" in front of the file string but you aren't using "folder" in front of the folder string. So try that. Second you can just use "alias" in front of the strings whether they're files or folders. There are other ways as well but I'll stop here. Either of those ways should work.
UPDATE: with all of the above being said, it seems System Events in 10.9 still has trouble with the move command. As such here's 2 alternatives for you. I used slash style paths since that's what you're using.
set somefilepath to POSIX file "/Users/Design_005/Desktop/Start/TextFile.txt"
set somefolderpath to POSIX file "/Users/Design_005/Desktop/End"
tell application "Finder"
move somefilepath to somefolderpath
end tell
or
set somefilepath to "/Users/Design_005/Desktop/Start/TextFile.txt"
set somefolderpath to "/Users/Design_005/Desktop/End"
do shell script "mv " & quoted form of somefilepath & space & quoted form of somefolderpath
Good luck.
You can’t do that. System Events can delete and open, but not move. Here’s a simple example in case it helps someone else find a better answer in a future OS. System Events appears to treat move differently than delete and open.
tell application "System Events"
set myFile to file "Macintosh HD:Users:velma:Desktop:Test.png"
set myFolder to folder "Macintosh HD:Users:velma:Desktop:Test"
--delete works! with both type “file/folder” and type “disk item”
--delete myFile
--delete myFolder
--open works!
open myFile
open myFolder
--move fails!
move myFile to myFolder
end tell
The error it’s returning, in this case, is “Can’t get file”, number -1728.
There appears to be bug in the move command in the "System Events" context in OX 10.9 (and possibly 10.8).
The workaround is the to use the "Finder" context instead:
Using HFS-style paths (separator is :)
set somefilepath to "Design_005_HD:Users:Design_005:Desktop:Start:TextFile.txt"
set somefolderpath to "Design_005_HD:Users:Design_005:Desktop:End:"
tell application "Finder"
move file somefilepath to folder somefolderpath
end tell
Using POSIX-style paths (separator is /) - as in the original question
set somefilepath to "/Users/Design_005/Desktop/Start/TextFile.txt"
set somefolderpath to "/Users/Design_005/Desktop/End"
# Note that we use `as POSIX file` even in the case of the *folder*
# - this works, however.
tell application "Finder"
move somefilepath as POSIX file to somefolderpath as POSIX file
end tell
Note:
as POSIX file returns a file object in both cases, but Finder still handles the move properly - it is fine to use POSIX file with both files and folders.
Note that using the prefix form of POSIX file- e.g., POSIX file "/Library", only works with a path string literal; if you try to build the path string as an expression, it breaks (in the "Finder" context, but NOT in the AppleScript context(!)): POSIX file ("/" & "Library") - by contrast, "/" & "Library" as POSIX file works (in both contexts) - go figure. To be safe, always use the postfix form: ... as POSIX file
A downside of using as POSIX file - at least as of OS X 10.9 - is that the error messages are cryptic if a file/folder doesn't exist: you'll see Finder got an error: Handler can’t handle objects of this class. and Finder got an error: AppleEvent handler failed. - both with number -10000.
(Using folder directly with a POSIX path, as in an earlier version of the question - e.g., folder "/Library" - ONLY works in a "System Events" context, and is therefore NOT an option in the "Finder" context.)
As for what changed in AppleScript OS X 10.9:
The behavior you see appears to be a bug (also see #Jerry Stratton's answer); nothing in the AppleScript release notes for 10.9 indicates a change in that area.
I now think that the problem affects OS X 10.8 as well.
I encourage you to submit a bug report to Apple at http://bugreport.apple.com, as I already have.
Sadly, handling files, folders, and aliases in AppleScript has always been a mess, with confusion stemming from classes of the same name from different dictionaries (AppleScript itself, System Events, Finder) with subtly different behavior.
A general recommendation: for file-system manipulation, use the tell application "Finder" context.
The "System Events" dictionary, in its Disk-Folder-File Suite, duplicates some of Finder's file-system manipulation functionality, but only some - a curious omission is a file copy command, for instance.
I'm executing the following line in an Applescript application.
set POSIX_path to "/Applications/iPhoto.app"
do shell script "sudo rm -rfv " & quoted form of POSIX_path with administrator privileges
The authentification screen pops up as it should but after authenticating the application just freezes upon executing this command. This problems only occurs in 10.9.
When I set the permissions of the folder to be delete to "everyone can read & write" it works.
Does anyone have a clue what has been changed?
EDIT: When I repeat the execution of this script by checking du -shx /Applications/iMovie.app it manages to delete a few more files with every try.
$ open compiled-applescript.app/
$ du -shx /Applications/iMovie.app
1.4G /Applications/iMovie.app
-- force quit AppleScript --
$ open compiled-applescript.app/
$ du -shx /Applications/iMovie.app
1.3G /Applications/iMovie.app
-- force quit AppleScript --
$ open compiled-applescript.app/
$ du -shx /Applications/iMovie.app
1.0G /Applications/iMovie.app
Its working fine on OS X 10.9 (13A603)
set POSIX_path to "/Users/paragbafna/Desktop/untitled folder"
do shell script "sudo rm -rfv " & quoted form of POSIX_path with administrator privileges
Does anyone have a clue what has been changed?
Well yes.. Gatekeeper has changed, that may be the cause..
When I set the permissions of the folder to be delete to "everyone can read & write" it works.
Did you do this from Finder or from the command line with chmod 0777? The latter may delete some attributes that Finder does not remove.
What setting is selected here, on your computer?
If you have a restrictive setting, try "Anywhere" to see if it solves the problem. If this is the cause you may:
Have custom command line tools installed, (e.g. MacPorts) or something you compiled yourself (since this is happening on 3 but not all computers and obviously you are not a "generic" user).
Your applescript is not being trusted, you can try signing it if possible, otherwise this may work:
If the user wants to run an application blocked by Gatekeeper, they have several options. Gatekeeper could, in effect, be turned off by letting it run all applications. A power user may opt to remove the quarantine attribute or use the spctl command to add a new policy in the security assessment policy subsystem. - TrendMicro - about Gatekeeper
Last resort idea.. Check your disk permissions, re-install Xcode if you use that, maybe the signatures are corrupted.
Write a shell script instead, I don't know if it is just about deleting a few files, then you can definitely do it in shell script, or comment to let me know what you're trying to achieve.
After days of trying everything to sort out this problem I finally found what was causing this issue.
It's the verbose-option (-v) of the rm-command. Leaving it out makes the application work flawless again.
Maybe Apple accidently introduced a buffer overflow. I will report this under the problem ID 15309626 I created at Apple's bugtracker. Maybe they'll fix it until the first 10.10 DP :D
So I've opened Textmate using Applescript, how do I tell it to open a specific folder?
EDIT: Tried Josh K's suggestion, but a strange error occurs. I ran this line:
do script "mate rails_projects/newproject"
And here is the result:
bens-macbook-pro:~ ben$ mate rails_projects/newproject
mate: failed to establish connection with TextMate.
But then, in the same console window, I'll type the same line that just failed,
bens-macbook-pro:~ ben$ mate rails_projects/newproject
and it works. Why would this be happening?
I would point the AppleScript to run the mate [folder] command, which will open TextMate with the specified folder.
I needed to do the same thing. Here's what I did.
tell application "Finder"
repeat with objItem in (get selection)
do shell script "mate " & POSIX path of (objItem as text)
end repeat
end tell
This will look at what files you have selected in the top most Finder window and then open them all in TextMate using the shell command "mate". Hope it helps!
The problem is likely that you're not telling AppleScript exactly where to find the mate command. Use the full path instead. Here's a simplified version:
set file_path to "/some/path/or/other"
set file_path to POSIX path of file_path
do shell script "/usr/local/bin/mate" & file_path
I'm a bit late to the party, but there's no need to use the mate utility for this, which may or may not be installed. The open command will do just fine. Something like this:
do shell script "open -a /Applications/TextMate.app /Path/To/Folder"