| Chris Adams | |
|
2008-7-1 06:23
Unix Quickie: redirecting to a pipe within a script
The bash exec function has an underutilized feature allowing you to redirect stdin or stderr for the entire script, avoiding the need to
make sure that the user always runs exec > example.`date +%Y-%m-%d`.log
Unfortunately, when the documentation says "If FILE is not specified, the redirections take effect in this shell" there's a key omission: you can't simply use a normal pipe to have your output go to mail, logger, etc. or in non-interactive environments like grid / batch schedulers which don't allow you to specify a pipe for job output. Googling won't turn up much useful other than some hacks which redirect to a temporary file/pipe or re-exec the script and I wanted something cleaner. The solution is to use the bash process substitution feature which allows you to create a file handle for a given command and use that where you might normally use a filename. This is normally demoed for cool input hacks such as diff-ing the output of two commands but it's also useful for our purposes: #!/bin/bash exec > >(mail -s "$0: normal job output" user@example.edu) exec 2> >(mail -s "$0: error job output" syadmin@example.edu) ... commands which will be executed normally ...
2008-6-13 14:43
Deleting items from the OS X Keychain using Python
Here's a simple example of how to use the Python ctypes module to load the Security framework on OS X and use it to delete an item from the keychain: keychain-delete.py
2008-6-12 16:31
Using DTrace to observe locking behaviour
Inspired by a talk, I'm getting around to posting a script I've been using for a bit over a year to track down locking performance issues on OS X, particularly with network filesystems:
If you spend a lot of time working on public networks or are worried about an unethical ISP injecting ads into your web pages, here's an easy way to keep your traffic intact and a bit more secure. OpenSSH has a handy DynamicProxy mode which allows it to provide a local SOCKS proxy: enable it and your traffic will be secure until it leaves your remote server. Besides thwarting a malicious network this is also a handy way to access intranet pages or things like scientific journals which restrict access to work/campus network addresses. The only drawback to using this is that it requires you to keep an ssh session open all the time - this is where launchd and OS X 10.5's built-in SSH agent support come in handy. Once you've setup public-key authentication you won't be prompted each time it restarts, so there are only two steps for seamless remote working:
If you use the standard Python logging library, the syslog handler doesn't work by default on OS X 10.5. The problem is that SyslogHandler assumes that it can send to localhost:514. In 10.5 Apple disabled network syslog by default, which is a good security measure but it means that previously working code will no longer work (rdar://5871746). The solution is simple - if you used to do
if sys.platform == "darwin":
# Apple made 10.5 more secure by disabling network syslog:
address = "/var/run/syslog"
else:
address = ('localhost', 514)
syslog = logging.handlers.SysLogHandler(address)
2008-4-17 08:16
Dinosaur meet tar-pit
A great example of how bad customer service works: Comcast cut David Winer's service for exceeding a secret transfer limit. He calls and is immediately confronted with a hostile legal department convinced that customers should pay for service they're not allowed to use. Hilarity ensues. The interesting question: will it be too late by the time the cable companies realize they don't have a monopoly any more? Bandwidth already has competition and now more and enough companies are starting to offer their content on iTunes, Hulu, etc. that the cable company's $60/mo is starting to look rather excessive…
2008-4-11 09:11
What do you do all day?
Finally, a blog-meme I can related to. Here's what I do all day at home and at work - numbers which I'm sure have changed dramatically since I started living in TextMate a few years ago:
chris@home:~ $ history|awk '{print $2}'|sort|uniq -c|sort -rn|head
166 python
52 ls
47 cd
37 ssh
34 svn
16 pydoc
16 mv
16 essh
15 vim
12 cat
cadams@work:~ $ history|awk '{print $2}'|sort|uniq -c|sort -rn|head
93 sudo
56 ls
53 cat
42 man
41 cd
25 svn
16 vim
14 grep
9 top
8 rm
2008-4-1 16:54
Tech writers: please stop talking about "iPhone killers" until you understand why real people love it?
For years the tech press has denigrated Apple users as being shallow flash-seekers. This is an amusing bit of projection given the key role they play in the hype-cycle, selling shiny-but-useless crap to anyone unfortunate enough to trust them. It's getting a bit annoying watching yet another repetition of the "iPhone killer" article which completely misses why the iPhone was successful. Here's Gizmodo breathlessly hyping the Samsung Instinct (“At Last, a Decent iPhone Competitor”):
Here's Gizmodo on the Instinct today pointing out that this is the kind of flash-without-substance everyone likes to accuse Apple of selling:
The thing which almost always gets ignored by tech writers is that iPhone has never been popular with people like the Gizmodo writers because it basically has one new feature (the multitouch interface); it otherwise ignominiously loses a feature–matrix comparison: no 3g, small screen, poor battery life, restricted bluetooth, no MMS, no third-party apps, no flash cards, etc. Everything on the feature list has been done for years by cheaper, less restricted competitors. Logically, this means that the iPhone sucks and the people buying it are brain-washed fashionistas, right? The catch, of course, is that feature matrixes only matter to marketing people and tech journalists who want to become marketing people. Everyone else tends to care more about how well a few basic features actually work - and that's where the iPhone shines, just as with the similarly disparaged iPod before it: I've been cell-phone only since 1999 or so and I've used a fair number of phones during that period. The iPhone is the first phone I've had which can honestly claim to have a usable web browser. It's also the first one other than the Palm devices to have an address book or calendar which are usable with more than a dozen entries. It's the first one which lets me dial my fiancé with less than a dozen clicks. It's the first phone I haven't needed to reset because it locked up or got unusably slow. Note how 3G didn't enter into the picture? It's not really necessary, any more than broadband was a prerequisite for the Internet to enter mainstream life. The trick was that Apple actually paid attention to usability and wrote software which does things like transferring email in the background so you don't have to wait - an advanced 1980s technique which could save Motorola if they copy it quickly (the SLVR my iPhone replaced couldn't scroll text anywhere near as fast as my old PC XT). Update:Here's another example from The Inquirer:
In theory, many phones are faster than the iPhone. In practice, the network engineers' hard work has been squandered by the poorly designed browsers shipped on just about everything else. The Instinct may avoid this trend but it's likely it will be yet another 3G phone which is slower than the iPhone if you browse on the phone but faster if you tether it to a laptop and use a real browser. This, incidentally, is another example of another over-emphasized iPhone critique: you can't tether a laptop but I've never needed to, either. A few hardcore road-warriors would need a 3G card but most people can find a WiFi hotspot if they need more than web+email. |
|