What's the point if I have to know about it and explicitly install it? Kind of ruins the surprise, but I guess I can set it up for unsuspecting others...
This has been around long enough that it was on the old Solaris workstations I used at my last job. Except on the Solaris boxes it actually made a very loud and obnoxious steam whistle noise to go with the animation, just to make sure everyone in the office knew that you mistyped `ls`. Turning down the volume didn't even work because it specifically sent the audio to the hardware speaker securely located inside the case.
Needless to say, I quickly added `alias sl=ls` to my .alias as soon as the embarassment subsided.
I hope that it actually performs an ls at a 1/10 probability -- just enough so that people will see it once in a while, but not enough to be relied on.
Along similar lines, a company I used to work for had a command-line tool called "metalink". If you mistyped it as "meatlink", your screen would fill with an ASCII-art rendering of the Japanese kanji meaning "meat", along with the legend "meatlink - the tastier alternative to metalink". (It would then go on to invoke metalink.)
I'm right-handed, and I make the typo all the time, to the point that I've aliased it. I think it's that I type it so quickly (both keys are in the "home row") that each key goes down at about the same time.
For some reason most of the guys I want to uni with (Heriot-Watt) had "alias l=ls" in their .config. I've not seen this with guys I know who were at other unis or with anyone I currently work with. I know it clearly wasn't pioneered at HW (very little outside the area of brewing and distilling is), but I wonder why it had such a high penetration there. Perhaps we were all equally lazy, or a teaching assistant suggested it 1st year and it stuck?
Hypothesis: the typo "sl" is only common among left-handers.
I shall have to add my vioce to the small left-handed chorus here and say that I too have never had an issue with the "sl" typo. In fact I cannot remember a single occasion where I have made this mistake.
I've intentionally left a typo that I did just make in the above paragraph to illustrate my own tangentially related observation: The typos that tend to occur within my own typing often seem to be the kind produced by one hand not two. By which I mean the typo "vioce" rather than "voice" happened because the fingers of my right hand hit the keyboard in the wrong sequence. Where as typos involving a finger from one hand then a finger from the other (as would need to be the case with "sl" rather than "ls") tend to be less common... for me anyway.
It was installed by default on one of my old debian boxes. The first time I stumbled upon it I felt like I was in the twilight zone. It took some time to realize what it was.
Somewhat off-topic, but why are people advocating Homebrew over MacPorts?
I've never found a port I thought should have been in MacPorts not being there, `sudo port -v install [package]` always seems to work, and dependencies are automagically followed.
Looking at the website, it seems the general "improvement" is that you can edit formulas before you install; but that's exactly why I use MacPorts! I don't want to know how to install all these things, that abstraction is something I prefer. If you don't intend to do this, is Homebrew really any different?
> Looking at the website, it seems the general "improvement" is that you can edit formulas before you install; but that's exactly why I use MacPorts! I don't want to know how to install all these things, that abstraction is something I prefer.
You can edit the MacPorts portfiles too, if you want to:
sudo port edit <portname>
I don't really understand why people are advocating Homebrew. The only real advantage seems to be the smaller dependency tree achieved by relying on Apple's shipped components, but that's a short-term band-aid that isn't going to last.
Homebrew tries to coexist with the pre-existing environment, whereas MacPorts and Fink create their own little isolated hierarchies in /opt and /sw, respectively.
Which means that if install Git, that's all I get. With Macports, I'll also be installing duplicate versions of at least curl, openssh, and rsync, as per http://help.github.com/mac-git-installation/
Which is a nice-sounding idea until the OS components are growing stale, at which point you'll be wondering why, for instance, your scripting language of choice's hash libraries don't support the modern idea of SHA256 (the answer being: because the OpenSSL version shipped with OS X was too old), or why your builds are now failing (because Apple shipped a library update without updating the headers in a Software Update).
Homebrew tries to take the high ground here, but it's just naivety. They'll wind up installing "duplicate" versions of software too -- in fact, they already are doing so. The short-cycle of Leopard -> Snow Leopard won't be happening again soon, and the only alternative to adding "duplicate" software to your dependency tree is letting software go stale (for example: python 2.7 vs SL's 2.6.1).
It's easy to say that the 10 years of knowledge that both MacPorts and Fink have about the platform is "stupid" when you haven't had the experience of maintaining a working packaging/port system through a few OS X release cycles, and aren't familiar with the problem space or Apple's policies.
Exactly, I use homebrew occasionally, but its really a pain because it doesn't keep its python libs in its prefix fr example. If you use non-system stuff it's a real pain in the ass.
I'm sure I'll get accused of having no sense of humor, but I have to observe that from a usability standpoint, this is unhelpful. It gives me no clue as to what I've done wrong, it wastes my time, and it offers me no help in correcting my behavior. I might install this on my personal machine for fun, but as a system administrator I have no business touching this.
Responding to invalid input by actively mocking the user is about the worst decision you can make for discoverability. It's this kind of user interface thinking that can lead to a toolchain being rejected regardless of how powerful or useful the tools could be.
I wonder if there is an equivalent for somebody who misspells ls -l as ls- l. That's one that nails me quite a bit, and all I can do is grumble as it takes few seconds for bash to realize that no, that's not a valid command anywhere in the system.
