This is the third instalment of an on-going series. These blog posts are only part of the series, they are actually the side-show, being effectively just my show notes for discussions with Allison Sheridan on my bi-weekly Chit Chat Across the Pond segment on her show, the NosillaCast Mac Podcast. This instalment will be featured in NosillaCast episode 418 (scheduled for release late on Sunday the 12th of May 2013).
In the first installment we started with the 40,000ft view, looking at what command shells are, and why they’re still relevant in today’s GUI-dominated world. In the second instalment we looked at OS X’s Terminal.app, the anatomy of the Bash command prompt, and the anatomy of a Unix/Linux command. This time we’ll be looking at the anatomy of file systems in general, and the Unix/Linux file system in particular, and how it differs from the Windows/DOS file system many of us grew up using.
This is the second instalment of an on-going series. In the first instalment I tried to give you a sort of 40,000ft view of command shells – some context, some history, a very general description of what command shells do, and a little bit on why they are still very useful in the modern GUI age. The most important points to remember from last time are that command shells execute commands, that there are lots of different command shells on lots of different OSes, but that we will be focusing on Bash on Linux/Unix in general, and Bash on OS X in particular. The vast majority of topics I plan to discuss in these segments will be applicable on any system that runs Bash, but, the screen shots I use will be from OS X, and some of the cooler stuff will be OS X only. This segment, like all the others will be used as part of my bi-weekly Chit Chat Across The Pond (CCATP) segment with Allison Sheridan on the NosillaCast Mac Podcast.
Last time I focused on the shell, and avoided getting in any way specific about the actual commands that we will be executing within the Bash shell. I thought it was very important to make as clear a distinction between command shells and commands as possible, so I split the two concepts into two separate segments. Having focused on command shells last time, this instalment will focus on the anatomy of a command, but will start with a quick intro to the Terminal app in OS X first.
I have no idea whether or not this idea is going to work out, but on this week’s Chit Chat Across the Pond segment on the NosillaCast Mac Podcast (to be released Sunday evening PST) I’m going to try start what will hopefully be an on-going series of short un-intimidating segments to gently introduce Mac users to the power contained within the OS X Terminal app. I’m on with Allison every second week, and I’ll have other topics to talk about, so the most frequent the instalments in this series could be would be bi-weekly, but I think they’ll turn out to be closer to monthly on average. While the focus will be on OS X, the majority of the content will be equally applicable to any other Unix or Linux operating system.
In the last CCATP we did a very detailed segment on email security, and despite the fact that with the benefit of hind-sight I realise it was too much to do at once and should have been split into two segments, it received the strongest listener response of anything of any of my many contributions to the NosillaCast in the last 5 or more years. I hope I’m right in interpreting that as evidence that there are a lot of NosillaCast listeners who want to get a little more technical, and get their hands dirty with some good old-fashioned nerdery!
- When the
custom_separatoroption was left blank, no separator was used, rather than the expected random separator.
- When the
custom_separatoroption was left blank or set to
RANDOM, and the
SEPARATOR, the results were un-expected, different random character was used for each, rather than the same random character.
For documentation and detailed release notes on version 2 of the module, see the release notes for version 2.0.
A few weeks ago on the Chit Chat Across the Pond segment of the Nosillacast, I mentioned that I had an OS X service set up to generate a random password using my XKpasswd Perl module and copy it to the clipboard. Listeners enquired as to how they would go about doing that, so as promised, here’s a quick tutorial.
Obviously this tutorial is for Mac OS X users only, because OS-wide Services and Automator are OS X features. The screenshots are taken on 10.8 Mountain Lion, but this same technique definitely also works on OSX 10.7 Lion, and probably even on 10.6 Snow Leopard. This tutorial also assumes that you have downloaded the
XKpasswd module, and saved it somewhere on your computer, along with either the sample dictionary file included with the module or one of your own making, and that you know where on your computer those files have been saved. In other words, you need to have
XKpasswd.pm and a text file with one word per line somewhere on your hard drive. In my sample code I’m going to assume you’ve installed the Perl module to the suggested location,
/usr/local/xkpasswd/XKpasswd.pm, and that you have customised the sample dictionary a little (more secure that way), and saved it to
I spent the weekend majorly re-factoring
XKpasswd.pm, my Perl random password generation library. V0.1 was the last thing I wrote before reading Perl Best Practices, and looking back on that code really illustrated the value of that book when used in combination with the perlcritic code analyser.
The new version of the module provides all the functionality the old one did, and more. The refactoring has made the module simpler to use from within scripts, as well as easier to modify and extend. Some new features have also been added, including the ability to use the www.random.org web service as the source of randomness for the library. A full list of bug fixes and new features is included below.
I had hoped to distribute this version as both a ZIP file and a .PKG file, but XCode 4.4 is not being cooperative on the new Mountain Lion, so that will probably have to wait until version 0.3.
Update – 6 August 2012: The link below has been updated to point to version 0.2.1 of the code. Details of the bugs fixed in the release notes.
I ran into a problem this week when the perl libraries for accessing MySQL databases refused to work on Mac OS X Lion. I did a ‘regular’ install:
- Install the 64bit version of MySQL Community Server (being sure to use the .dmg version so as to get the .pkg installer)
- use CPAN to install the needed database libraries:
$ perl -MCPAN -e shell
cpan> install Bundle::DBI
cpan> install DBD::mysql
There were no errors during the install, so I assumed all we well, until I tried to actually use the libraries to access a database that is! Using DBI to try connect to a MySQL database gave the following error:
- install_driver(mysql) failed: Can't load '/Library/Perl/5.12/darwin-thread-multi-2level/auto/DBD/mysql/mysql.bundle' for module DBD::mysql: dlopen(/Library/Perl/5.12/darwin-thread-multi-2level/auto/DBD/mysql/mysql.bundle, 1): Library not loaded: libmysqlclient.18.dylib
- Referenced from: /Library/Perl/5.12/darwin-thread-multi-2level/auto/DBD/mysql/mysql.bundle
- Reason: image not found at /System/Library/Perl/5.12/darwin-thread-multi-2level/DynaLoader.pm line 204.
After a lot of googling I found plenty of people with the same problems, including people on Snow Leopard, so I figured this was not a new problem. I tried a number of the suggested solutions, and most did not work, but after two days of trying, I found one that did, and it was wonderfully simple!
The problem is that the MySQL libraries are not in the OS’s library path, so they are not being found, most of the proposed solutions tried to tackle the problem at compile time, or to use simlinks to hack the libraries into the path, but like I say, these solutions didn’t work for me. What did work is simply updating the library path in my environment!
If you run the command below before executing your Perl script the library is found and all is well!
It’s a little awkward to do this all the time, so I added the line to my ~/.bash_profile file, and now it just works for me!
I spent two frustrating days trying to fix this, so hopefully I’ll save others some time by sharing my solution.
Steve Gibson really set the cat among the pigeons with his Password Haystacks site a few months ago, and XKCD’s ‘Correct Horse Battery Staple’ web comic brought that message home to many many nerds and geeks. The basic idea is that you’re better off making your passwords long and memorable than short and complex. In the simplified XKCD example the password is simply made up of 4 common words, but Steve Gibson suggests you should add some padding around those words to make the passwords much harder to guess.
This is a lovely theory, but I’m not imaginative, and I need to invent a lot of passwords every week, so I wrote a Perl module to do it for me, and called it
xkpasswd.pm. The first thing I’m announcing today is that I’ve made this library available for free for both personal and commercial use (under the FreeBSD license), you can download it from www.bartb.ie/xkpasswd.
It’s great to have a library for nerds to play with, but what about everyone else? Well, that’s where my second announcement comes in, I’ve also created www.xkpasswd.net, a simple web front-end to the
In case anyone is wondering where the name comes from? It’s a mashing together of XKCD, and
passwd, the Linux/Unix command for changing passwords. Because I used to use Solaris, and hence the
yppasswd command, I liked the idea of keeping the prefix to just two letters, hence
xkpasswd, rather than
For any programmers interested in using the Perl module, it has no prerequisites other than base Perl, and all you need to get started is the module and a dictionary file to point it at. The download package contains the module, a sample dictionary, and a sample Perl script which invokes the module.
I’ve been looking at different free Mac AV solutions so that I can make recommendations to less-computer-savy family members, and this afernoon I decided to give ClamXav a go. I’d tried it a few years ago and wasn’t very happy, but I’d been told by friends that it has improved a lot since, and a first glance at the GUI suggests they’re right. Unfortunately I didn’t get very far with my initial testing this afternoon because I’m in an environment where I have to use an HTTP proxy server to access the net, and ClamXav appears not to support proxies at first glance. It ignores OS X’s system-wide proxy settings, and it has no interface elements of its own to allow you to specify a proxy server manually. This implies that ClamXav doesn’t support proxies, but it actually does, they just didn’t bother to expose that functionality through the GUI.
ClamXav is just a GUI wrapper for the free and open source Clam AntiVirus toolkit, and it uses Clam’s regular auto-updating tool
freshclam. Although the ClamXav GUI doesn’t give you control over the variables in the
freshclam configuration file, that file does exist as part of ClamXav (
/usr/local/clamXav/etc/freshclam.conf), and if you edit it manually it will respect the settings specified in that file. If you’re not afraid of the Terminal, you can easily edit this configuration file manually to get ClamXav to use a proxy server for updates.
I’ve lost count of the amount of Twitter clients I’ve tried, and none are perfect. There may well be a client out there that does everything I need exactly how I want it to, but I’ve yet to find it. In recent times I’ve settled on Syrinx because it ticks most of the boxes, but it’s not perfect. I haven’t been actively search for a new client, but I’ve still been keeping my ears open. Hence, when Tim Verpoorten talked about Itsy on a recent episode of the Mac Review Cast I decided to give it a go.