LinLog

For the last few years, I've been using this tool called "go" - an eminently unsearchable name. Basically, it's kind of like bookmarks for the command line - you can set directories to be remembered and go back to them with a single short command.

Anyway, shortly after I started using it, I posted a patch that added support for Powershell (which I call go-posh). That worked well and everything was fine. Then, a bit later, I added a few more small patches to the application, such as an option to print the directory path rather than changing to it.

Well, that was all well and good. I'd been using my patched version every day for quite a while. I even added it to my Mercurial repository for safe keeping.

What I didn't realize is that I never updated my original blog post with my second set of changes. I discovered this the hard way a couple of weeks ago, on the computer at my new job. When I set up go-posh on that computer, I just used the ZIP archive from my blog post, rather than cloning it from my Mercurial repository like I normally would. It worked just fine for a few weeks until I tried to run something like gvim (go -p sb/somefile.txt) and was informed that the -p option didn't exist.

I hate it when I do things like that. It's such a stupid mistake and it's extra embarrassing because it's been wrong for nearly three years.

Anyway, I've updated the old blog entry. That's a little out-of-date now anyway, so I also linked it to the project tracker page, which is the canonical source of information anyway. I even rebuilt the Mercurial repo to reflect the actual changes I made to the stock install, rather than the context-free initial import I had before.

So anybody who's interested should grab the code from there. The additions over what I used to have in the blog post download include the aforementioned -p option, as well as resolving of shortcut prefixes when they aren't ambiguous (e.g. if the shortcut is "downloads", you can just use "dow"), home directory detection for Windows, and improved support for the -o options. You can see more info in the README.txt file.

Like many geeks, I have an Amazon Prime subscription. In addition to free shipping on many orders (which may well pay for the subscription by itself), Prime comes with a number of other features, such as streaming of selected Amazon Instant Video titles (which also paid for my subscription the last two years by having all of the Stargate series), and 5GB of free storage on Amazon Cloud Drive, which will be my topic for today.

Now, I actually kinda like some aspects of Could Drive. It's not terribly expensive - it's $0.50/GB per year and they offer six teirs from 20GB to 1TB. It integrates with my Kindle Fire HD and they have nice, unobtrusive apps for Windows, Mac, and Android that keep your files in sync. The Android app even has a nice little option to automatically sync any pictures you take to your cloud drive. So it works pretty well for me.

The one problem with Cloud Drive is sharing. Normally, that's not something I care a great deal about. However, there's that photo uploading feature of the Android app that I mentioned. And let's face it - if you have a smart phone, then it is your camera. And if your camera is automatically uploading pictures to your Cloud Drive, well then it makes perfect sense that you would share the pictures from your Cloud Drive when you want to send them to your friends and family.

Except you can't.

Well, to be fair, you actually can. You just won't want to because it sucks too much.

Maybe it would be easier to actually show you the problem. First, here's how you share a file in Cloud Drive:

Nice and simple - you select a file and click the "share" item in the menu. Self explanatory, isn't it? That'll give you a dialog that looks like this:

It's got a nice preview and the share URL and everything. Sweet!

Now, here's another picture. See if you can spot what's different.

Did you catch them both? One was that there were two files selected this time instead of one. The other one is that the SHARE ITEM IS FREAKING DISABLED!

So I can't share multiple files? Well, that's OK - I'll just move them both into a folder and share the entire folder. Except that I can't because sharing is FREAKING DISABLED ON FOLDERS!

So what's the upshot of this? Well, if I want to share all those nice photos that my phone has so helpfully auto-uploaded, I have to do it one at a friggin' time. That means my workflow looks like this:

1. Select a photo in Cloud Drive.
2. Click the "share" menu item.
3. Copy the share URL from the dialog.
4. Paste that URL into an e-mail or something.
5. Dismiss the dialog.
6. Return to step 1 and repeat for the next item.

Sure, for a handful of items, this isn't a big deal. But what happens when you have a couple dozen photos you want to share? Does Amazon seriously think I'm going to sit there and painstakingly share each individual file, noting down the share URLs? Not a chance in hell. I'm going to take advantage of the fact that Cloud Drive desktop app syncs them to my PC to bypass Amazon and just upload my pictures to another site with non-crappy sharing features. (I've been using Sta.sh, mainly because I'm familiar with it, what with having spent nearly two years helping to build it when I worked for deviantART.)

The thing that really bothers me is that this isn't a new problem. It's not like Amazon just rolled out the sharing feature and it's going to be improved very soon. If this were just a temporary stop-gap then I could forgive it. But it's been like this for a while. I don't remember when I first noticed this, but I think it's been a year or more.

And the worst part is that this is just such insultingly bad product design. Seriously, has nobody at Amazon even tried to use this freaking thing? Is the product manager just so oblivious that it never occurred to him that maybe people might want to share more than two pictures at a time? And did nobody above or below him bother to question it? Or is it just a case of trying to shut up some of their more vocal customers who demanded this by giving them a crappy, mostly-broken version of what they asked for in the hopes that they'll go away?

There are loads of other ways to do this that would solve the problem. And I get that there may be some non-obvious technical limitations to some of the possible solutions. I've seen such issues myself when I was working on Sta.sh. For instance, maybe there are back-end issues that make sharing folders actually much harder to implement than it would seem. That's fair.

But even so, is there really any excuse for this? After all, Cloud Drive is all AJAX-based, so is there any reason why they couldn't have done the UI in a way that would allow multi-sharing? I know I certainly can't think of one. It wouldn't even be hard. All you'd need to do is enable the "share" menu for multiple selections, have it fire off one AJAX request per item to get the share URLs, and then aggregate them in a text area so that you can copy and paste them en masse. I'm not saying that would be ideal, but it would be better than what they have now. Plus it would be easy. Heck, I even think I could implement that in a Greasemonkey script if I really wanted to - I looked at the AJAX requests and they're not complicated.

So seriously, Amazon, get your act together. I don't know who signed off on this half-assed feature, but they need a smack in the head. It's almost 2014 - this crap doesn't fly anymore.

I've discovered a small caveat to the technique for OSX-like trackpad behavior that I posted about the other week. I probably should have anticipated this - it seems fairly obvious in hindsight, but didn't seem so at the time.

It turns out that X-Mouse runs in a different user context than the Window UAC dialog. Who knew, huh? The upshot is that any button that's been configured with X-Mouse will revert to its default behavior in the UAC. In other words, you have to click the system-default "left button" to make the dialog work.

Not actually a huge deal, since your X-Mouse config comes back once the elevated process has been launched, but a bit weird.

Note: This post is mostly a note to myself. I don't do this often and I always forget a step when I need to do it again.

I have Mercurial set up on my hosting provider. I'm using hgweb.cgi and it works well enough. However, Mercurial does not seem to support pushing new repositories remotely when using this configuration. That is, you can't just run an hg push on the client or anything like that - you need to do some manual setup.

The steps to do this are as follows:

1) On the client, do you hg init to create a new repository.
2) Copy this directory to your server in the appropriate location.
3) On the server, edit your new_repo_dir/.hg/hgrc to something like this (if you have one that you copied form step 1, just nuke it):

[web]
allow_push = youruser
description = Some description
name = your_repo_dir

4) Add a line like this to your hgweb.config:
your_repo_dir = /path/to/repo/your_repo_dir

Assuming that the rest of the server is already set up, that should do it. I always keep forgetting one of the last two steps, for some reason (probably because I only do this once in a while).