You are currently browsing the category archive for the ‘fixes’ category.
Fix for “caution: filename not matched” error when trying to unzip multiple files at once in Terminal.
Solution for unzipping multiple zip files with a single command.
Open up a Terminal window on OS X, go to the directory containing the zip files and enter this command:
unzip \*.zip
The forward slash escapes (prevents) the wildcard character (the “*”) from being expanded by bash shell interpreter. In English: the files in the directory are the filenames “unzip” is trying to extract from the first file it finds when using “*”.
Example:
/myzips directory contains zip files: first.zip second.zip third.zip
Trying to run: “unzip *.zip” will cause the unzip program to take “first.zip” as the archive to play with, and will look for files “second.zip” and “third.zip” within “first.zip” to expand/extract. Obviously not what you want to do.
Not escaping the * character will result in errors like: “caution: filename not matched”.
First find your current sleep setting by opening Terminal in OS X and entering this at the prompt:
pmset -g | grep hibernatemode
That should return you something like “hibernatemode 3″. Remember this number, send an email to yourself, write it down on a scratch pad, whatever it takes to remember your default mode. Mode 3 keeps your RAM powered during sleep to allow super fast wake-up, but also writes an image file of all memory onto disk in case power is lost.
To change the hibernate safe sleep setting to not create an image file on the disk, i.e. mode 0 (mode zero, not the letter ‘o’), enter the following in a Terminal window:
sudo pmset -a hibernatemode 0
Enter your password when asked to do so. This prevents Safe Sleep from saving your memory contents to disk, in large part the cause of not being able to wake MacBook’s from sleep.
If you’d like to get back about a gigabyte or more of disk space, delete the memory image file with the following Terminal command:
sudo rm /var/vm/sleepimage
Macworld has a great article with more information about safe sleep and hibernation on MacBooks.
Open the lid and nothing? Tap keys, change brightness, close and re-open lid and your MacBook still in sleep mode?
Solution: Turn off Safe Sleep. Or use Smart Sleep.
If you open your MacBook lid and notice that you can’t wake your MacBook from sleep, it’s because of the Safe Sleep system Apple designed. This system puts all your current memory (your RAM) onto the disk, so that it can power down the RAM, save energy, and keep the current working state of your computer, even if you ran out of battery power, changed batteries, etc.
Problem is, it’s slow. And buggy. Often when waking from sleep by opening the lid, the MacBook will remain in sleep.
My solution to this: don’t use Safe Sleep. Unless you’re constantly working on battery power and hate plugging in, you likely won’t ever notice you’re not using Safe Sleep’s hibernate to disk mode.
Here are some instructions on how to turn off Safe Sleep on a MacBook Pro Leopard or Tiger to avoid wake-up problems.
If you still want to use Safe Sleep with disk caching of RAM, use Smart Sleep by Patrick Stein. This software adds a preference pane to your Mac, allowing you to not use disk hibernation until you reach a low battery level, say 20% remaining battery.
While watching a tv series encoded with divx, in avi package format on a Macbook installed with Leopard, I noticed that Front Row would randomly crash and return to the desktop.
First step in investigating what was causing the crash is to look at the syslog.
- Open up Terminal (Applications => Utilities => Terminal)
- Go to the /var/log directory (cd /var/log)
- View the syslog file (less system.log)
- Go down to the latest entries in the log file (Shift + G)
- Look for a line saying “Saved crashreport to /Users/[username]/Library/Logs/CrashReporter/Front Row_2008-04-27″ or something to that effect. The username will be your Mac OS X username and the date attached to the Front Row text will of course be different. These crash logs are created whenever a program you are running stops for some unknown reason (i.e. a crash).
- Press “q” to quit the “less” program.
- Goto the CrashReporter directory (cd /Users/[username]/Library/Logs/CrashReporter). Replace [username] with your username.
- Open the latest Front Row crashlog with “less” (less Front Row_2008_2008-04-27). If you’re having trouble typing the name, just hit the Tab key, which will attempt to fill in the blanks as best as possible, creating spaces with escape characters.
- Look for the line saying “Crashed Thread” and note the number beside it. In my case it was “22″.
- Now use the search function within “less” by hitting forward slash “/” then typing “Thread 22″. This is case sensitive so make sure you capitalize “T” in Thread.
- You should see Thread 22 Crashed: followed by what file was related to the crash of Front Row. In my case it was listed as “com.yourcompany.XviD_Codec”.
If you continue reading, you’re doing the following AT YOUR OWN RISK. You can royally screw up Front Row and any type of movie/video watching by performing the following, so if you have any qualms, do not perform the next steps.
My fix was to move the AppleIntermediateCodec.component and AppleMPEG2Codec.component files from /Library/QuickTime to a backup directory and replace it with Xvid_Codec 1.0 alpha.component which is detailed in another post on how to watch xvid encoded avi files on Mac OS X. To move these two files elsewhere, create a backup directory on your home directory (mkdir ~/QuickTime_backup) then use the “mv” command (mv AppleIntermediateCodec.component ~/QuickTime_backup/) (mv AppleMPEG2Codec.component ~/QuickTime_backup). Now install the alpha xvid component for Mac.
Make sure QuickTime isn’t running, or fully Quit QuickTime and then start Front Row and attempt to watch the same file that was causing Front Row to crash before.
The reasoning behind removing these two QuickTime codecs is that they aren’t on another MacBook book of mine, which doesn’t have Front Row crashing problems. That’s the only logic I have behind this fix.
So far, the change has worked.
Best of luck.
To reduce the temperature of my MacBook Pro I use smcFanControl by Hendrik Holtmann. Normally my MacBook Pro would run somewhere close the 55-60C mark without doing anything intensive, say a 10-15% average CPU utilization. I found this somewhat hot for my tastes, especially when using the built in keyboard where it would be uncomfortably hot to touch the speaker/heat dissipation grilles on either site of the keyboard.
I generally run the two internal MacBook Pro fans at 2600rpm each to keep the temperature 50C or below, depending on ambient temperature. The cost is a little fan noise which is noticeable in a dead quiet room. If you’ve got any music or background noise, you won’t notice it. Either way, it’ll blend into the background quickly since it’s “white” noise anyways.
I’m unsure which version is the latest for smcFanControl so here’s another link to smc Fan Control version 2.1.2 in case it’s more recent than the above link.
This post was due to a comments discussion on how to turn off the macbook pro display when using an external display for Front Row.
I recently copied over a set of PDF ebooks from an external drive to my “home” folder (usually your login name under Places within Finder) and a few minutes after that my Macbook Pro fan started to go nuts and I noticed my CPU temperature was up near the 70 degree C mark.
Cutting to the chase (fix): Open up System Preferences -> Spotlight Preferences -> Click Privacy button -> Click + button at bottom left and add the directory where you’ve just put your PDF files. In a few minutes, ATSServer will stop going nuts.
I quickly loaded up Activity Monitor (found under Applications -> Utilities in Finder, if nothing shows up after starting Activity Monitor, hit Apple key + 1), sorted processes by CPU descending (by clicking on the CPU column) and noticed that a process called ATSServer was hitting about 60% CPU time with mdworker below it at about 23%.
These two processes were really chewing up processor time and I had no idea what I had done to set this off, having never seen ATSServer before, I googled “What is ATSServer?” and found a forum thread on support.apple.com where people were batting around theories of what was causing ATSServer to go nuts.
For me it turned out to be the PDF books that I had just copied over to my Documents folder. Turns out that Spotlight, Apple’s file and text indexing service, tries to parse text in files, make thumbnails of pdfs (dear god),
and many other things including the kitchen sink.
Here’s an excerpt from Apple on Spotlight (warning PDF file) when they released Spotlight with Tiger (OS X 10.4):
Spotlight is comprehensive. Spotlight searches across your documents, images, movies, music, PDFs, email, calendar events, and system preferences. It can find some- thing by its text content, filename, or information associated with it, known as metadata. This allows you to find a photo by entering the brand of camera that took it, the name of the person who emailed it to you, or the date you last opened it.
I guess Spotlight is a bit too ambitious when it comes to PDF files. Simply copying over 300MB worth of PDF docs shouldn’t cause Spotlight to lose its mind. My guess is that it’s attempting to parse all the text within the PDFs and put those results into Spotlights database. Result: nastiness. PDF’s are exactly “fun” to parse I guess.
If you’ve noticed that your Macbook or Macbook Pro purchased in 2006 or 2007 is losing its battery life at an alarming rate, you’re not alone. Apple has had a very large batch of Sony lithium-ion polymer batteries for their laptops that are losing their maximum charge capacity very quickly.
If you’ve noticed that your 4 hour battery life dropping to just over 2 hours recently, check your System Profiler for some information about your laptop battery power system.
System Profile can be found in Finder => Applications => Utilities => System Profiler.
Once you have System Profiler open, find Power underneath Hardware. Click on that item and on the right side of the window, scroll down until you find the Battery Information heading.
The three values we’re interested in are Full charge capacity (mAh), Cycle count, and Battery health.
A normal reading for Full charge capacity is about 5200-5400 mAh (milliamp hours). That translates into just over 4 hours battery life. Cycle count is how many times the battery has been used to capacity and recharged. Battery health is a word describing overall life expectancy and condition of the battery.
Remember that Apple has published on its Apple Support site that their laptop batteries are designed to hold 80% of its original charge capacity after 300 cycles (see the footnotes).
Doing the math, that means the Full charge capacity should be around 4160 to 4320 mAh after 300 cycles. If your Macbook battery is failing, like mine, it should read less than 3250 mAh, with a Health of “Fair” after far less than 300 cycles.
But, don’t despair. With that juicy price paid for the best laptop available on the market comes pretty good customer service. Bring your Macbook into an authorized service center, an Apple flagship store, or call up Apple support hotline and explain the situation. Also note that there are several support forum threads on Apple.com about users describing the same situation and what Apple has done for them:
http://discussions.apple.com/thread.jspa?threadID=1227431&tstart=0
http://discussions.apple.com/thread.jspa?threadID=1300374&tstart=0
For Macbook users experience battery life problems as described above the warranty coverage is being extended to two years, so even if your Macbook is out of warranty, your battery may still be in warranty.
I currently have a battery being sent to me and we’ll see how things turn out.
Good luck.
Update: This post has been superseded by How to Fix Ajax Error: permission denied to call method XMLHttpRequest.open.
For anyone developing S-controls and applications for use in Salesforce.com, developing directly within their platform is a bit of a hurdle. Using their Ajax Tools Development Environment for quick changes is fine. But, developing a serious piece of code purely using that tool is far from a pleasant reality today. Hence its natural to develop on a local machine then upload to Salesforce.com when a piece of software is ready for testing within the platform.
When trying to use the Ajax Toolkit connection.js library locally, you’ll encounter a cross domain scripting error:
“Permission denied to call method XMLHttpRequest.open”
Cross domain scripting is not allowed by default in Mozilla based browsers (Firefox, Camino, etc.).
To override this security feature you need to add the following line to your XMLHttpRequest code before issuing an open() call:
netscape.security.PrivilegeManager.enablePrivilege(“UniversalBrowserRead”);
This allows the user agent (browser) to ignore cross-domain scripting warnings, which are a major source of cracking attacks.
There are one or two more steps required to make this work depending on whether you’re using Firefox or Camino. The following step is the same for any Mozilla borwser, be it Firefox, Camino, or any other Mozilla based web browser agent.
In the browser address window type:
about:config
This opens the Mozilla configuration file which you can filter using the field at the top of the screen and edit items by double clicking on them.
Find signed.applets.codebase_principal_support
By default it should be set to false. Double clicking it should set it to true.
For Firefox users, this next step is also necessary: adding a capability.policy line to the user.js config file which contains all user preference settings for the browser. Regardless of which operating system you’re using, user.js does not exist by default. Therefore, you must create this file, then add the appropriate settings into it. The settings from user.js get copied to prefs.js, which is the actual file read by Firefox.
On Mac OS X the correct directory to create this file within is:
~/Library/Application\ Support/Firefox/Profiles/[alphanums].default/
On Win XP or 200:
C:\Documents and Settings\[User Name]\Application Data\Mozilla\Firefox\Profiles\
Note that [alphanums].default is a jumble of letters and numbers “dot” default and it is a directory. For example “o3dfi34z.default”. Within this directory create a file named “user.js”. Within this file add the following three lines:
user_pref("capability.policy.XMLHttpRequestToAnySite.XMLHttpRequest.open", "allAccess");
user_pref("capability.policy.XMLHttpRequestToAnySite.sites", "http://localhost.com:3000");
user_pref("capability.policy.policynames", "XMLHttpRequestToAnySite");
Now note that “http://localhost.com:3000″ is only in my case. Whatever your local development location is, use that, be it “http://localhost”, “http://192.168.1.1″, etc. etc., use that. Be exact with this site address. It matters. For me, that port number was required for Firefox to allow me to send XMLHttpRequests to another domain without being denied.
Try running the XMLHttpRequest again and hopefully your Permission denied to call method XMLHttpRequest.open error has disappeared.
For those of you trying to use the Salesforce.com connection.js Ajax library locally, these are the following edits I made to make this happen. The following line numbers relate to version 11.1 of connection.js.
Find the definition of sforce.Transport, which should be around line 565.
Find the line: this.connection.open("POST", this.url, async); around line 591.
Add the following line before the previous line:
netscape.security.PrivilegeManager.enablePrivilege("UniversalBrowserRead");
Change the relative URL paths for the Salesforce API from “/services/Soap/u/11.0″ to the following:
"https://www.salesforce.com/services/Soap/u/11.1"
A nice way to do this is simply add a constant at the top of connection.js and just replace all occurrences of the relative path with this constant:
const sforce_api_url = "https://www.salesforce.com/services/Soap/u/11.1"
After that, fire up your trusty browser and try making your Ajax Toolkit call again.
You may find it helpful to use a Javascript development environment like Jesse Ruderman’s Javascript Development Environment 2.0.1 when playing around with Javascript. [Jesse, you're the man]. Install it as a bookmarklet for the best user experience. It allows you to access all the javascript code and the document model in your current browser window through this development environment (which opens up in a new window).
Don’t forget the about:config stuff with the browser up above.
And finally, this is for debugging purposes on your local machine. Don’t publish code which disables security settings (which are there for a good reason) to a live deployment environment, such as Salesforce.com. Normally you’ll be installing the code you’re building as an S-control anyways, within the Salesforce.com platform, which will be exempt from any cross-site cross-domain scripting issues.
With Ruby on Rails 2.0.2 fresh out of the gates and hordes of (us) DHH fanboys coding away in Textmate on their Macs will soon realize that the new .rhtml template is now .html.erb. This file extension isn’t recognized as Rails (HTML) by default in Textmate 1.5.7.
All you need to do is edit the correct Textmate Bundle which you get to by finding in the Textmate Menu: Bundles -> Bundle Editor -> Show Bundle Editor -> click the arrow beside Ruby on Rails -> near the bottom of the list click on Rails (HTML), then on the right hand side area find:
fileTypes = ( 'rhtml' );
and change it to:
fileTypes = ( 'rhtml', 'erb' );
Greg is the man and posted the original fix to the Textmate html.erb bundle problem.
