SonicChicken
A bumbling foray into tumblr...
Yet another instance of Apple telling me what they are doing, and me failing to pay attention. sigh…
In this case, I recently “upgraded” my system at work, from the 3rd newest to the 2nd newest version of OS X. But after I did so, I lost all my developer tools (compiler, make, perl’s CPAN, etc.)
It turns out that all I needed to do was reinstall Xcode, but that’s now done via the App Store instead of the interwebz. Also, after installing Xcode, you need to run it so that you can have Xcode install the command line tools.
Steps #1 and #4 take a bit of time, but once they were done I had a config.h and CPAN was working again.
Step #5 might take a little explanation. The command line tools that I was missing were make(1) and cc(1). I thought cc might be a little easier to find, so here’s what I did:
$ which cc
(nothing returned)
$ locate cc | grep /cc$
/Developer/usr/bin/cc
$ export PATH="$PATH:/Developer/usr/bin"
The first command verified that my PATH did not include the cc command. The second one (locate) showed me which directory it was in. And the third one added that directory to my PATH for the current session. Once you’ve verified that your tools are all working, copy that “export PATH…” command to your .bashrc file.
I might have avoided some of this trouble if I had kept up with What’s New in Xcode
Cueing up some Jim Croce…
The meanest hunk o' woman
That anybody ever seen
Down in the arena
One of the tools I make the most use of is email. I like Apple’s mail.app (which comes with OS X), but it’s vastly improved with a couple of extras from indev.ca: Mail Act-On and MailTags. I use this combination on all my Macs, and the only major hurdle is keeping the Act-On rules the same on all my systems. A quick browse of the indev.ca knowledge base brought me to Manually moving Mail Act-On rules. This turns out to be fairly easy to do, if you designate one of your systems as the “master”. Just copy the following files from that system to your “slave” systems:
Remember that the Finder won’t show your ~/Library folder unless you explicitly “Go To Folder…” (shift+apple+G on keyboard).
The section on advanced bash scripting tops is always worth going back for a re-read! There are a lot of nuggets of platinum among all the gold. :D
Of course, this assumes familiarity with the previous sections of the bash scripting guide.
Earlier this year, a minor change to Pod::Simple caused brian d foy’s Mac::Errors module to fail during testing. The underlying problem is an ASCII/UTF-8 issue. One might expect the utf8 pragma to fix this, but remember that POD ignores all the code outside of POD elements.
Aristotle Pagaltzis makes an excellent point in the comments on bdf’s post, mentioning that it’s a Bad Idea to mix your POD and program text encodings.
Since I’m using a Mac, UTF-8 characters are pretty likely to end up in my code and/or POD. It seems prudent to follow the suggestions from bdf’s article:
In the source code, include the utf8 pragma: > use utf8;
Declare your Pod encoding as utf8: > =encoding utf8
(update 2013-03-26) The encoding command has been a part of perlpod since at least version 5.8.8, based on that version’s documentation:
http://perldoc.perl.org/5.8.8/perlpod.html
According to that documentation, the encoding should be the first pod directive. It can appear anywhere (not necessarily within a documentation block), but it must only appear once.
Since that’s a perlpod command, it needs its own paragraph (i.e. two consecutive newlines). And since the “use utf8” and “=encoding utf8” work together, it’s probably a good idea to include this in the header:
use utf8;
=encoding utf8
The blank lines before/after encoding must be completely empty. An easy way to check that (and many other perlpod requirements) is podchecker(1).
I love the `find(1)’ command! But sometimes I don’t want the default fully-recursive behavior. For example, today I wanted to do something with all of my “dot files” without affecting “dot directories” (such as .ssh) or their contents:
find $HOME/.* -prune ! -type d -exec ls {} \;
The `ls’ command is just for demonstration purposes. Substitute with a useful command of your choice.
I originally found this on Con Poco Coco’s tumblog, but the link was broken. The URL for afp548.com seems to be the same material. Below is the original post from Con Poco Coco:
This guide is for setting up homebrew to build individual packages that can be deployed with munki or ARD.
(404 URL: http://osxdeployment.com/wiki/Homebrew_Packaging_Guide)
Charles’s Krypted.com blog has a useful post about setting Apple hardware firmware passwords. The efipw.py script works great on the MacBook Pro (13-inch, Mid 2010) machines I tested it on. However version 0.2b does not work on newer models (see below for list) as Paul Makowski notes on the project page. Interestingly enough the python script is still able to decrypt the password on the newer models. Thankfully one must run it as root (or via sudo) to do that otherwise this whole firmware lock exercise would be moot.
The Apple Way(tm) of setting EFI firmware passwords is to use an application on the install DVD called Firmware Password Utility. Since I have gone to all the trouble of setting up DeployStudio and Munki to automate the management of the hundreds of Macs under my care, it is poor option to boot from the DVD and manually set the firmware password. There are many reasons for this, but the number one is manual entry leads to errors. (I should note, not having verification steps also leads to errors, but that is for another blog post.)
What is an automating loving sysadmin to do?
