stringByExpandingTildeInPath, which returns a string made by replacing any initial "~" or "~user" component with the corresponding path. This is useful because it (and its companion,
stringByAbbreviatingWithTildeInPath) let the user use the same paths their shell lets them use, within your application.
Eventually, it annoyed me so much that I wrote something to translate "~" to
System.getProperty("user.home"). And then I found myself assuming that because "~" worked in my Java applications, "~user" should work too. So I came up with code that assumes that "~user" is equivalent to "~/../user/", and for some time now I've been happy.
I might have preferred that Java did this for me. I might have preferred that
Filewas called something more honest like
Pathname, and was a bit more useful (some understanding of symbolic links, say). But given that I'm not in a position to fix the JDK, I was relatively content.
I knew Objective-C programmers had it better, and I knew GTK+ programmers had it worse. (Where did the plus come from? The same place as "Professional" or "Advanced" in conjunction with MS Windows, I suppose.) But I assumed that they'd at least copy and paste the tilde-handling code into each of their great fat C slugs.
Not GNOME Panel, though. I tried to launch "~elliotth/Projects/edit/edit" and was informed that it didn't exist. I knew it did. But I checked anyway. I'm a developer; I make a living from questioning my assumptions. It existed. "Interesting", I thought, "that it doesn't show me the pathname it handed to exec; it's generally good practice to present user-friendly forms to the user, but in an error message you should show exactly what you're using ... maybe that is what they're using?"
They were. Nice! By the time Linux is ready for the desktop (and it will be years yet), it won't be recognizably Unix any longer. And those of us who love Unix will be running Mac OS, I guess.
Which is fine by me.