From the sed manpage:

-i extension
   Edit files in-place, saving backups with the specified extension.
   If a zero-length extension is given, no backup will be saved.  It
   is not recommended to give a zero-length extension when in-place
   editing files, as you risk corruption or partial content in situ-
   ations where disk space is exhausted, etc.

This doesn’t work:

sed -i -e's/apples/oranges/' file.txt

The key thing here is that the extension after the -i flag is not optional. If you leave it off, sed assumes you’ll be entering it via stdin, which isn’t allowed and yields this error:

sed: -i may not be used with stdin

The solution is to send a zero-length extension like this:

sed -i '' -e's/apples/oranges/' file.txt

Careful with this, it could be really dangerous with poorly crafted commands.

Ran the Sunrise Lake loop this morning. Sunrise Lake’s elevation is 1,440 feet above sea level, which, considering that I normally run at sea level, made the hills seem that much more difficult.

Ran the 4.5 mile Hudson River route with Harris. Started out at dusk, which was amazing.

Four miles in 35 minutes on the treadmill.

Update: Amazingly, iPhone 1.1.2 update re-enabled the m4r-rename hack. This all works again!

I just tested it quickly by renaming a previous home-made ringtone file to m4r and double-clicking. It imported, synced to and played on my iPhone without any other steps.

Currently there are no known ringtone hacks for iPhone 1.1.1.

Apple, you’re pissing off your fans. Don’t do this. [we’ll just be over here pretending you listened!]

This totally seems like it shouldn’t work.

If you’re seeing “cannot be played on this iPhone errors” like this:

Open your iTunes Library folder and find the Ringtones folder: iTunes Music/Ringtones.

Select your ringtone and change the file extension back to m4a. Yes, m4a.

Sync again and your custom ringtone should be working on your iPhone. Nice.

Update: Confirmed for Windows XP & Vista

Thanks to commenter Robbie, building on steps from Jason Choi, here’s how to get custom ringtones working in Windows:

1. Put m4r files into a ringtones folder on my desktop
2. Opened iTunes
3. Edit > Preferences > Advanced
4. Check “Keep iTunes Music folder organized”
5. Check “Copy files to iTunes Music folder when adding to library”
6. Create playlist called “Ringtones” in iTunes
7. Drag the Ringtones folder from my desktop to the playlist I created in iTunes
8. Made sure they appeared when in the list on the Ringtones tab in iTunes
9. Opened the “Ringtones” folder that iTunes created in MusiciTunesiTunes MusicRingtones
10. Renamed all the m4r files to m4a
11. Try to sync but it fails because it cannot find the m4r files (this is good)
12. Look at playlist created in iTunes with a bunch of Xs next to each ringtone
13. Double click each ringtone (hit browse for the file, and selected each m4a file from the folder in my MusiciTunesiTunes MusicRingtones)
14. Hit sync again
15. Verify they are in your Settings>Sounds>Ringtones

Me, yesterday:

The price drop on iPhone was shocking. I was all set to buy a new Nano, but the idea that my iPhone now costs one-8GB-nano less has me waiting. This seems like a big enough PR blunder, or setup, that Apple will followup with some easy goodwill. I’m still going to get a new nano, but I’m going to wait at least until the weekend.

Today Apple does it again: To all iPhone customers

…[W]e need to do a better job taking care of our early iPhone customers as we aggressively go after new ones with a lower price. Our early customers trusted us, and we must live up to that trust with our actions in moments like these.

Therefore, we have decided to offer every iPhone customer who purchased an iPhone from either Apple or AT&T, and who is not receiving a rebate or any other consideration, a $100 store credit towards the purchase of any product at an Apple Retail Store or the Apple Online Store. Details are still being worked out and will be posted on Apple’s website next week. Stay tuned.

We want to do the right thing for our valued iPhone customers. We apologize for disappointing some of you, and we are doing our best to live up to your high expectations of Apple.

I think they fully expected this reaction having done something similar to quell outrage after dropping the price on Aperture last year. It’s a win-win for Apple, if there was no outrage, then eh, they just sell more phones. If there is outrage, as there was, Apple wins, probably more.

The intial news cycle only lasts so long, Apple got some press for the new iPods yesterday, then got more as the media picked up on all the iPhone owners who felt robbed.

All publicity is good publicity.

Apple waited just long enough for things to die down a little, then grabbed everyone’s attention again with a remarkable conciliatory, gesture of goodwill. Happy customers, more coverage. The initial news cycle stretched two or three times what it was and ends on an undisputed high note.

It’s called public relations for a reason. How much does it cost to grab people’s attention? How much to stay at the top of the news cycle?

Apple is playing the game masterfully.

And my new iPod nano is suddenly half off.

For some reason I’ve put off setting up SSH key pairs, probably having something to do with how arcane most of the setup instructions appear. Tonight however, I’m unexpectedly preparing to transfer a client to a new hosting account on Media Temple and enjoying key-pair access to their new repository.

Media Temple doesn’t yet support svn:// access to Subversion repositories, only svn+ssh://. So, having been pushed, I finally decided to make my life easier with SSH key pairs.

The best tutorial I found was Allan Odgaard’s: Subversion support and ssh key pairs. Without ssh key pairs, all the fantastic Subversion integration in TextMate won’t work with svn+ssh:// repositories.

However there’s one crucial piece of information missing from that: Permissions.

If access to the SSH configuration files is not properly assigned, the ssh pair won’t work. No meaningful errors at connect time, just silent, infuriating failure.

The ~/.ssh directory permissions need to be set to 0700 and the authorized_keys file needs to be set to 0600:

chmod 0600 ~/.ssh/authorized_keys
chmod 0700 ~/.ssh

If group or world have write access to authorized_keys, key pair authentication will fail.