This hint shows how to remove the Diginotar System Root certificate. You must be an administrator to take this action.
Open KeyChain Access, and select System Roots under Keychains. Type 'diginotar' in the search field on the upper right. When I did this only a single certificate was left in the list of certificates. Select that certificate and press the delete key. Confirm that you want to delete it, and expect to enter your password.
Note: I right clicked on this certificate and selected 'delete' a couple of times but that did nothing.
[crarko adds: This hint was actually submitted prior to the release of Apple Security Update 2011-005 for Lion and Snow Leopard. That update handles this issue for those versions of the OS, but there is no update for Leopard or earlier systems, so these still require manual fixing. For stronger measures than what is included in this hint, I refer you to this excellent article on the subject.]
I always assumed this was just the Bluetooth Diagnostics report, but when I clicked it, it created a ZIP on the Desktop: BluetoothReporter_DATE_TIME.zip.
This file is far more useful than I suspected. It contains:
kernel.log
PacketLoggerBluetoothTraceFile.pklg
system.log
system.log.0.bz2
SystemProfilerReport.spx
WebProcess_DATE_TIME_COMPUTERNAME.crash
This is all in one neat Zip file, in two clicks from the Desktop. It's worth it for the System Profiler Report, System Log and Crash Reports alone.
Perfect for sending to a Service Provider or engineer for diagnosis.
[crarko adds: This is really handy. I've used it myself to help in trying to debug an iOS app I was working on, that used Bluetooth within the Simulator.]
It's widely known that the OS X Services infrastructure was completely overhauled (and made significantly more useful) in Snow Leopard. What virtually no one seems to be aware of is that Apple released a 'Services Manager' tool as long ago as 2009, which offers significant advantages over using the built-in support in the Keyboard preference panel.
In Snow Leopard (and now in Lion), it's possible to create your own Services (using e.g. Automator), and it's also possible to disable or enable Services provided either by applications or the system itself, by going to the Keyboard Shortcuts tab of the Keyboard preference panel.
However, the Keyboard preference panel has a number of limitations when it comes to editing Services, and unfortunately these limitations add up to it being just about unusable in practice. For example, while you can activate or deactivate a particular Service, there's no way to specify whether that Service will only be available on the Services menu, or (much more usefully) on relevant contextual menus as well. OS X seems to decide which Services appear on contextual menus based on its own arcane rules.
Services are listed by name only in categories based on their function. There's no easy way to see whether a particular Service is offered by the system itself, a third party application, or (say) an Automator workflow in /Library/Services or ~/Library/Services.
Back in pre-10.6 days, when there was no officially supported way of editing Services, a free tool called Service Scrubber by Many Tricks Software could be used for this purpose. Due to the changes made to Services in Snow Leopard, Service Scrubber no longer works in 10.6+. I've often wished there were a modern replacement.
As it turns out, there is! A tool named Service Manager is provided by Apple itself, hidden away on its macosxautomation.com website. You can download it here, and you'll find it provides all the functionality mentioned above, and more. Services Manager was intended for use with Snow Leopard, but I have so far found no problems using it in Lion.
[crarko adds: Works the same in either Lion or Snow Leopard. This is a great little utility.
Note: since some people seem to be freaking out in the comments here is some referential information about Sal. He's pretty much the boss of Services.]
Database Events.app (one of the scriptable background apps that appeared in Tiger) is intended to give some basic access to the sqlite3 database system. It has been generally maligned as a not-too-useful app, and in fact I am one of the people who has maligned it that way. But while playing around with it today I discovered that it is actually much more powerful than anyone seems to realize. Thus, a quick hint to clue everyone in.
First, don't set your hopes too high: DE is not a full-featured SQL processor. There are no tables, no meta-structures, not even a built-in sorting system. The database DE makes is just a simple flat list of records with fields, much like single-page spreadsheet. So for instance, you build up a dataset like follows (this creates a database and populates it with random data):
tell application "Database Events"
set db to make new database with properties {name:"tester", location:(path to desktop)}
tell db
repeat with i from 1 to 15
set thisRec to make new record with properties {name:"Record " & i}
tell thisRec
-- A field called 'name' - e.g. name:"name" - is automatically linked of the
-- to the 'name' property of the record, above; doesn't matter which you set.
make new field with properties {name:"first", value:(some item of {"alpha", "beta", "gamma"})}
make new field with properties {name:"second", value:(some item of {1, 2, 3})}
make new field with properties {name:"third", value:(some item of {"double-u", "ex", "why", "zee"})}
end tell
end repeat
close saving yes -- this clears the database out of memory
end tell
end tell
Run this and you'll see a file called 'tester.dbev' appear on your desktop. You can use this newly created database in the obvious ways, like so:
set db to (POSIX path of (path to desktop)) & "tester.dbev"
tell application "Database Events"
tell database db
--get the third record by index
set a to name of record 3
--get the value of field 'first' of every record
set b to field "first"'s value of records
-- set the value of field 'second' of the record "Record 11"
set value of field "second" of record "Record 11" to "Boo"
end tell
end tell
But what's not at all evident is that each search is itself an object that you can modify, search on, and otherwise work with. For example:
set db to (POSIX path of (path to desktop)) & "tester.dbev"
tell application "Database Events"
set bill to database db
tell database db
-- set the value of field 'second' to 'hey' wherever third's value is 'why'
tell (records whose field "third"'s value is "why")
tell field "second" to set its value to "hey!"
end tell
-- set the value of field 'second' of any record whose name is "Record 11" (note the plural)
set value of field "second" of records "Record 11" to "Boo"
-- delete any record whose name contains '1'
delete (records whose name contains "1")
--get the name and the value of field 'second' where the value of field 'third' is 'ex'
tell (records whose field "third"'s value is "ex")
set c to {name, value of field "second"}
end tell
close saving yes
end tell
end tell
So as you can see, once you get this trick of using compound objects Database Events becomes a reasonably powerful tool, at least for quick and simple databasing.
[crarko adds: The only other real reference I could find to Database Events.app is here. The application is found in System » Library » Core Services. The article referenced above gives more information about scripting Database Events.]
There are many hints that involve the use of the defaults command to change system settings. When trying to keep my Macs in sync (as well as setting up new ones), I have difficulty remembering which changes I've made. So after some work I was able to build a script that nicely tracks the changes I make to the system.
My requirements were to log any writes or deletes, showing both the old value and the new value to a log file in ~/Library/Logs/ where it is accessible to Console. (I use logger too but those messages get lost in the noise and are aged off). I wanted to leave any other defaults command (read, find, etc.) alone.
My first try was to write a function in my .bash_profile, which is loaded at every login and overrode the executable. That seemed fine until I realized that when using sudo defaults, it wasn't working. This is because sudo simply executes a command as different user without logging in and getting the benefit of profiles. It changes certain environment variables and drops all functions and aliases. So the most important changes of all were missed.
My solution was to create a script and place it in the path prior to /usr/bin/defaults. Thus when sudo calls the command without profiles, it runs the script instead of the binary (you could also do this with a link if the path is a problem).
I export a variable with the path to log file and define a log function that includes the date/time in my .bashrc so it's available to every bash shell invoked (login or not) under my username. You can easily just put these lines in the script itself, but it turns out to be convenient to be able to log anything at the terminal with the function, so I define it in ~/.bashrc:
#!/bin/bash
# Defaults - a script to record important changes to the system
source ${HOME}/.bashrc
if [[ ! ${1} ]]; then
echo "This is the script version of defaults. Run /usr/bin/defaults to see help"
exit 1
fi
if [[ (${1} == write) || (${1} == delete) ]]; then
op=${1}; dom=${2}; key=${3}; shift; shift; shift; args="${@}"
[[ (${op} == write) && ("${args}" == "") ]] && args='""'
log "${USER} executed defaults ${op} ${dom} ${key} ${args}"
logger "${USER} executed defaults ${op} ${dom} ${key} ${args}"
log "existing value: \"$(/usr/bin/defaults read ${dom} ${key})\""
logger "existing value: \"$(/usr/bin/defaults read ${dom} ${key})\""
/usr/bin/defaults ${op} ${dom} ${key} ${args}
log "new value: \"$(/usr/bin/defaults read ${dom} ${key})\""
logger "new value: \"$(/usr/bin/defaults read ${dom} ${key})\""
else
/usr/bin/defaults $@
fi
Note that the single and double quotes are difficult to see but nonetheless important. Also note the usual complaints by defaults when changing a key that does not exist still apply -- it complains but does actually make the change.
If you have some app that you always want to keep open -- in my case it's Stickies and DragThing, which I use frequently -- it's easy to set up the computer to do that for you.
For example, to keep Stickies permanently open, remove Stickies from the login items for your account (if you've placed it there), quit Stickies, and then create the following plist file in the LaunchAgents folder of your home Library (~/Library/LaunchAgents) with the name user.launchkeep.stickies.plist:
Stickies will now effectively be un-removable -- any time it quits, crashes, or gets forced-quit it will pop right back up. If fact, in order to quit the app at any time other than logout or shutdown you'll need to disable the job; In Terminal type
launchctl remove user.launchkeep.stickies
Or you can set up a script that does that for you.
Note that you have to use the path to the inner executable, not the path to the app package - you can find this by right clicking on the app icon, choosing Show Package Contents, and navigating down to the MacOS folder where the main executable is stored. If you do something wrong, the general result will be that the app is not only kept alive, but in fact keeps launching every 10 seconds or so (launchd's throttle time-out), so that it keeps grabbing screen focus, which is very annoying. if that happens, just unload the plist, make sure it is correctly written and the app is quit, then load it again.
Sometimes when I move between spaces, the little animation freezes (doesn't fade away), and it blocks out all keyboard access. I can still move between spaces (though this usually doesn't unfreeze it), and use the mouse.
I used to fix this by quitting the Dock with Activity Monitor (which was annoying because I had to do the whole thing only with the mouse), but today I discovered that if I press the Dashboard key on my keyboard (it's F12 by default), it unfreezes it (and it doesn't even open dashboard).
[crarko adds: I haven't tested this one. Any ideas about why this should be the case?]
A bad cold has temporarily robbed me of my voice, so I decided to pay homage to Stephen Hawking and whip up a poor-man's vocalizer. More fun than function here, but it did let me order my latte at Starbucks without pain, and with a great many laughs all around.
Run this from the AppleScript Editor, save it to the Scripts Menu, or save it as an Application; whatever method works best for you.
property currentVoice : "Vicki"
set systemVoices to {"Agnes", "Albert", "Alex", "BadNews", "Bahh", "Bells", "Boing", "Bruce", ¬
"Bubbles", "Cellos", "Deranged", "Fred", "GoodNews", "Hysterical", "Junior", "Kathy", ¬
"Organ", "Princess", "Ralph", "Trinoids", "Vicki", "Victoria", "Whisper", "Zarvox"}
repeat
activate me
set theResult to display dialog "Say What?" default answer ¬
"" buttons {"Quit", "Speak", "Change Voice"} ¬
default button "Speak" cancel button "Quit"
if button returned of theResult is "Quit" then
exit repeat
else if button returned of theResult is "Change Voice" then
set currentVoice to item 1 of ¬
(choose from list systemVoices with prompt "Choose new voice.")
end if
if text returned of theResult is not "" then
say text returned of theResult using currentVoice volume 1
end if
end repeat
[crarko adds: I tested this, and it works as described. I thinks it's a simple and clever usage of a well-known Mac feature.]
Here is a quick AppleScript droplet to bulk convert text files (plain text, rich text, html, some code files like C and javascript files...) to PDF format.
Copy the following script into the AppleScript Editor (/Applications/Utilities/AppleScript Editor) and save it as an application.
Then drag-and-drop files onto it to convert them to PDFs.
on open theFiles
set oldTID to AppleScript's text item delimiters
repeat with thisFile in theFiles
-- get file path as posix path
set inputFilePath to POSIX path of thisFile
-- create output path - same name with .pdf extension
set AppleScript's text item delimiters to "."
set outputFilePathBits to text items of inputFilePath
set last text item of outputFilePathBits to "pdf"
set outputFilePath to outputFilePathBits as text
-- create convert command and send to shell
set AppleScript's text item delimiters to " "
set cmdList to {"/System/Library/Printers/Libraries/convert", "-f", quoted form of inputFilePath, "-o", quoted form of outputFilePath}
do shell script (cmdList as text)
end repeat
set AppleScript's text item delimiters to oldTID
end open
The new PDF files will be put in the same folder as the originals.
The convert utility is not well documented (enter /System/Library/Printers/Libraries/convert without options in Terminal to see the brief help menu), but it's really just a front-end for the cupsfilter utility, which has better documentation. If you're a CUPS expert you might be able to do more with it than this, but for simple conversions this does nicely.
[crarko adds: I tested this, and it works as described.]
You can use AutoIT, a free basic-like GUI scripting application to automate the bootcamp.exe in Windows to force a reboot back into OS X.
This is sort of part 2 to my previous hint found here. This AutoIT script can be automated by whatever mechanism you use to manage a Windows partition on your Macs, like Active Directory, Citrix, Novell/Netware, SCCM, or other third party tools to run scripts and policies in your enterprise.
It basically just opens the Boot Camp executable file in Windows and then simulates mouse clicks. This is how I forced users back into OS X after non admins would boot into Windows. Here is the script:
;; boot_to_osx.au3
;;
;; there's no way to do this with the command line or anything,
;; so here's a little autoit script to use apple's provided
;; utility to bless the OSX drive.
#requireadmin
Local $dom = envget("USERDOMAIN")
;;runas("maptestadmin",$dom,"m4pt3st",0,"C:\Windows\system32\AppleControlPanel.exe")
Run("C:\Windows\system32\AppleControlPanel.exe")
WinWait("Boot Camp Control Panel")
WinActivate("Boot Camp Control Panel")
WinWaitActive ("Boot Camp Control Panel")
ControlClick ("Boot Camp Control Panel", "", "[CLASSNN:SysListView321]", "left", 1, 40, 20)
ControlClick("Boot Camp Control Panel", "OK", 1)
Run("C:\Windows\system32\shutdown.exe -f -r -t 0")
You can find the AutoIT software from their site, and it is a free product. In our case we had Zen Works auto launch and monitor our testing application that users needed to use Windows on. Once that process was terminated in any way at all, the AutoIT script kicked off and forced a user back into OS X. We only wanted our users using Windows for that single application and nothing else.
