In general all programs call on the operating system to do things. These are the API - application programming interface.
Lion changes some API, adds new ones, and deletes old ones. The biggest problem is when a program needs an API that is now gone. The second issue is when things change. Lastly, when a new feature like Mission Control is introduced, perhaps the older program isn't expecting it's windows to be moved around in that manner.
The assumptions made by a developer can turn out to no longer be true which will cause little or big glitches.
Also - programs that don't use API but just react to things as they are can break when those things move. For example - if a program assumed ~/Library is visible - then it would clearly break when running on a clean version of Lion.
Device drivers change - that can cause errors.
Lastly, entire compatibility layers like Rosetta are dropped.
For anyone who ends up on this page, I realized I should post the answer:
Using launchd instead of cron does indeed fix the authorization problem. Your user launchd jobs (which run only when you are logged in) correctly use the SSH agent information that was unlocked via your keychain as part of login (as part of standard OS X key management, no other software required).
To minimize my interactions with launchd, I created a single launchd job that calls a bash script. In this way I can simply edit the script without dealing with launchd.
Here's the launchd file:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>com.mycron.hourly</string>
<key>ProgramArguments</key>
<array>
<string>/Users/john/bin/cron.hourly</string>
</array>
<key>Nice</key>
<integer>1</integer>
<key>StartInterval</key>
<integer>3600</integer> <!-- start every X seconds -->
<key>RunAtLoad</key>
<true/>
</dict>
</plist>
I saved the file to ~/Library/LaunchAgents/com.mycron.hourly.plist, and then loaded it with:
launchctl load ~/Library/LaunchAgents/com.mycron.hourly.plist
Once loaded, it will run right away and then again every 60 minutes.
If you follow the same procedure, you'll want to change the `ProgramArguments' string with the right path to your script.
Best Answer
Within bash, the command
echo $BASH_VERSIONshows the version of bash. You can then look up what changed in the changelog file, which is bash's case is calledCHANGES. (There's a more complete changelog in the sources, but it's mainly of interest to people who write and maintain bash.)If your machines are up-to-date, they'll be running the same version. Make sure all the external programs used in the script are up-to-date too: the script may behave differently because one of these programs produces different output.
You can watch what your script is doing more closely by running
bash -x /path/to/script. The-xoption makes bash print a trace for each command that it runs. You can also putset -xin a script to turn tracing on, andset +xto turn it off.