LinLog

PowerShell highlighting in Vim

pageer@skepticats.com (Peter Geer)

Well, I feel stupid. I just finally got syntax highlighting for PowerShell to work in Vim. I did a little Googling and found my solution in the PDF document linked form this article. Why you need an 8 page PDF to explain this is a completely different issue.

Turns out I was just missing some lines in my filetype.vim file. I already had the syntax, indent, and file type plugins, I just didn't think to add the code to activate them (for some reason I thought that stuff was loaded dynamically). However, page 6 of that PDF gave the answer:
" Powershell au BufNewFile,BufRead *.ps1,*.psc1 setf ps1
I just added those lines to my filetype.vim, below the corresponding entries for Povray files, and voilà! Syntax highlighting now works.

Editing FAT32 file attributes

pageer@skepticats.com (Peter Geer)

Here's a quick and useful tactic for dealing with file attributes on FAT32 drives. I got the idea from this post on the Ubuntu blog

My new MP3 player (which I'll be blogging about when I have more time) uses a FAT32 filesystem. I needed to change the attributes on some of file attributes so that it would show the media folders but hide the system folders. Why I needed to do that is another story. Anyway, the point is that there was no obvious way to do this from Linux and since charging the MP3 player seems to reset these attributes, I didn't want to have to rely on a Windows machine being handy.

After way more Googling than I thought necessary, I discovered that you can do this with good old mtools. The really old-school people in the audience will probably remember them from the days when floppy disks were still in common use. Well, it turns out that they can be used with USB mass storage devices too.

The first step, after installing mtools of course, is to set up a drive letter for your USB device in your ~/.mtoolsrc file. This can be done by adding something like the following:
drive s: file="/dev/sdb1" mtools_skip_check=1
The first line associates the S: drive letter with the device file for my player. The mtools_skip_check line suppresses errors which, I believe, arise from the fact that this is a USB device, not an actual floppy disk. Either that, or there's something about the FAT that mtools doesn't like, but can still work with.

Once that's set up, I was able to simply use mattrib to change the file attributes and [cdoe]mdir[/code] to show the attribute-sensitive directory listing. The actual commands look something like this:
mdir S: mattrib +h S:/TMP mattrib -h S:/MUSIC
Note the use of the S: drive letter to prefix paths on the root of the device. The +h and -h flags turn the hidden attribute on and off respectively. Also note that you can have the device mounted while doing this - mtools doesn't need exclusive access as far as I know.

Eventually, I'll be scripting this so that I can (hopefully) run it automatically after charging my player. Ideally, that script would include some HAL or udev magic to detect the dynamically assigned device node and add that to the mtoolsrc file. When I get around to writing that, I'll post the result.

USB drive pain

pageer@skepticats.com (Peter Geer)

It's time for another tale of IT pain. You remember CRAPS, the pathological police system we're required to use? Well, it struck again.

Today I had to travel to a nearby police agency to assist them with their CRAPS installation. They were having problems with the data transfer between the field units and the office. This is normally accomplished via a removable USB drive. In order to ease this procedure, CRAPS includes a feature to automate the copying of data files to and from the USB drive. Basically, the user clicks a button and the data files get compressed and moved in the appropriate direction.

The problem with this feature is that it's not very friendly from a configuration point of view. You see, CRAPS doesn't actually know anything about USB drives. It just knows about paths, and they're configured statically. So you actually have to tell the software, "use drive F: for the data transfer."

What's worse, CRAPS isn't even very smart about handling paths. As you probably know, when Windows detects a USB mass storage device, it assigns it the next available drive letter, so you can't depend on the same devince getting the same letter every time. However, CRAPS requires that a CRAPS administrator configure the drive letter ahead of time and it cannot be changed by a regular user. So the user ends up with, for example, a drive with multiple partitions, he can't use it until an administrator can reconfigure his system. Which sucks.

The first problem today was that CRAPS can't even join paths properly. We were having problems with the data transfer feature mysteriously failing on a couple of workstations. The USB drive path was correctly set to E: in CRAPS. However, just on a lark, because I know how cranky CRAPS can be, I tried chaning it to E:\. And you know what? It worked. *THWACK* (That's the sound of me smacking myself in the head.)

My second problem was partly Windows, partly the fact that I didn't set up this other agency's network. You see, on one workstation, the USB drive was being mapped to F:, but the primary network share was also being mapped to F:. The result? The network share clobbers the USB device and you can't access the USB drive until the network share is disconnected.

This is a fairly well known problem. As I understand it, the cause is that drive mapping is done on a per-user basis, and while network shares are mapped by the user, USB drives are mapped by a system account. There are a number of possible fixes, of course, but they all kind of suck - especially if you don't have any significant ownership over the system you're working on.

Nothing is ever as easy as it should be. Which is why "IT land" sucks.

Sympathy for the devil

pageer@skepticats.com (Peter Geer)

I know there are those in the Linux community who will regard this as equivalent to spitting on the cross while blaspheming the holy spirit, but sometimes I feel sorry for the people at Microsoft. They have a tough job and they are frequently blamed for things that aren't their fault.

What made me think of this was Jeff Atwood's follow-up to his Windows spyware post.

I understand the pressure to be backwards compatible. There's no end of Vista blowback based on minor driver compatibility issues. The "if it doesn't work, it's automatically Microsoft's fault, even if the software or hardware vendor is clearly to blame" mentality is sadly all too common. But given the massive ongoing Windows security epidemic, was defaulting regular users to Administrator accounts-- exactly like Windows XP, Windows 2000, and Windows NT before it-- really the right decision to make?

In many ways, Microsoft is in a perpetual no-win situation. On the security front, for example, they are besieged by the evil forces of malware. However, every time they try to improve the situation, end users scream blood murder. For example, was the weird "quasi-administrator with prompting" a good idea? Probably not, but it's better for the average user than silently allowing the installation of spyware, and yet everyone seems to hate it. But what's the alternative? To make accounts regular users by default? How would the average Windows user would feel about that? I don't know, but I have read a many comments by recent converts to Linux who seem to think that entering a password just to install some software is completely stupid and unreasonable, so I can't imagine it would be universally hailed as a great improvement.

And, of course, there's always the breakage that accompanies any OS upgrade. For example, remember Windows XP Service Pack 2? I seem to recall widespread complaints about things breaking when that was rolled out. And we're seeing the same thing now with Vista. And who do people blame? Is it the ISV who are still coding with Windows 98 in mind? No - they blamed Microsoft.

What really kills me about this situation is when I read Raymond Chen's accounts of the efforts of the Windows App Compatibility team. For example, consider this sample chapter from his book. From the cases he mentions there, it is completely obvious that Microsoft takes backward-compatibility seriously. Very seriously. In fact, you might even say they take it too seriously.

Think of it this way. On Linux you're lucky if you can get source compatibility for an application that's more than 5 years old. Microsoft has binary compatibility with a large range of programs that are 10 or 15 years old. They're working with third-party binaries, diagnosing obscure bugs, and implementing fixes to keep the applications working, even though it's by sheer luck that they ever worked in the first place. As a programmer, it's hard to overstate how impressive this is. And yet all anyone ever focuses on is the problems they didn't fix.

Then there's the political angle. There are lots of people out there who seem to think that Microsoft can do no good. Everything they do is viewed with suspicion. Anyone who works for Microsoft has to contend with accusations that he is either in on the conspiracy or is bowing down to "the man" every time he says something they MS-haters don't like. That's got to be at least a little demoralizing. And while a certain degree of animosity is certainly warranted (as it is with practically any large business), it's not like Microsoft has been running child sweatshops or dumping toxic waste in the local drinking water. It just seems way out of proportion.

So no matter what the people in Redmond do, it seems like there's always somebody pissed off at them. And it's a shame, because they really do do some good work. The .NET world has lots of neat technologies and is a very cool place for developers. Even though OpenOffice may be good enough for many, MS Office is by far the best office suite available. And, last but not least, Windows, despite it's flaws (and they are legion) is a very impressive feat of software engineering. Not to mention that Microsoft employs a number of very bright people.

So, to the Linux community, I say, let's give Microsoft a chance. I'm not asking you to like MS, or to start using any of their products. Let's just be honest and realistic. Most people in the community aren't shy about placing the blame on them, but give credit where credit is due. We rightly object when people blame free software for not being a panacea, what with hardware incompatibilities and the lack of certain software. We should at least hold MS to the same standard and not judge them for failing to satisfy everyone.

Windows has problems with FAT32?

pageer@skepticats.com (Peter Geer)

Here's a weird one. For some reason, my Digitalway MPIO FL100 MP3 player can't see files that are copied onto the removable SD card from Windows. But files copied from Linux show up fine. Is it just me, or does that seem a little backwards?

What happened was that I wanted to listen to a few podcasts this morning. I didn't feel like running downstairs to get the SD card out of the MP3 player, and I didn't want to download them from work, so I just dumped the files on my USB thumb drive before I left the house. When I got to work, I whipped out my portable USB SD card reader, copied the files from the thumb drive to the SD card, and slapped the SD card back in my MPIO. I turned the player on, started browsing the playlist and...nothing. The files just weren't there.

My frist thought was that something must have gone wrong. Maybe I disconnected the card too early and the files didn't copy. So I hooked the SD card back up to my Windows XP workstation and checked. Hmm.... The files were definitely there. Were they corrupt? Didn't seem to be. The file sizes looked right and they played in Windows Media Player.

Maybe it was because the card was almost full. It's a 1GB SD card and there were only 6MB left. Maybe the MPIO can't quite address a full gigabyte. So I moved the files I was trying to play off the card, deleted a few old files, and moved the new ones back. OK, now I've got about 50MB free, which has always been enough before. But when I plugged the card back into the MPIO, it was still a no-go.

After a few more unsuccessful variations on this same process, I started to wonder if the problem was with the SD card reader or even Windows itself. After all, this never happened with my internal SD card reader on my home Kubuntu system. So just for the heck of it, I fired up a copy of Kubuntu running in VMware. I plugged in the SD card reader, moved the MP3s off the card, unmounted and remounted, and moved them back on. This time, when I put the card back in the MPIO, it saw the files. I was able to select them in the playlist and they played perfectly.

At this point, the question is: What the hell happened? According to fsck.vfat, the SD card uses a FAT32 filesystem with long filename support and doesn't show any errors. Theoretically, Windows should be able to read and write that with no problems. And it can - but not in a way the MPIO can read. Is there some extension to FAT32 that Windows uses but Linux and the MPIO don't? Is this due to some implementation-specific detail where the MPIO agrees with Linux but not Windows? There's got to be some rational explanation for this. Does anybody have any ideas?

Learning KDE things from Windows

pageer@skepticats.com (Peter Geer)

It's funny how learning things about one platform can teach you about another. Despite all the differences, there are still lots of little similarities that carry over from one to another. In a way, it's kind of comforting.

Take today, for example. I was having a slow day at work, so to control the bordom, I downloaded some old episodes of Scott Hanselman's podcast, Hanselminutes. The episode in question was on the top ten Windows tools/features you didn't know you had. The first tip (#10) was that you can still use the keyboard in the middle of a drag-and-drop operation. So, for example, you can still alt+Tab, use a VirtuaWin hotkey to switch desktop, and just generall do a bunch of stuff I never thought to do with drag-and-drop. It just struck me as both very handy and so obvious I can't believe I never thought of it.

So, naturally, the first thing I did was try it out. Unsurprisingly, it worked and was very cool. And just as naturally, the second thing I did was fire up Kubuntu Edgy in VMware to see if it worked in KDE. And guess what - it does! Not that I should be surprised - there's no reason I know of why it wouldn't work in KDE. It's just that when you go back and forth between Linux and Windows, you get used to the idea that everything is always different. This was one of those "freebies" you discover every now and then that makes you feel nice.

In fact, the relative closeness of KDE to Windows is what attracted me to it in the first place. I started off with the Unices back when GNOME and KDE were in the 1.x releases and - let's face it - they both sucked. Thus I was an old-school AfterStep user for several years and then migrated to ROX and Sawfish. But while ROX was nice, and I really bought into the idea of how it worked, the user experience was just too different from Windows. After a while, going back and forth started to feel jarring. I just had to bring the two closer together. And since there's not much you can do about the interface for Windows, it was obvious that the Linux side would have to change.

I really appreciate it when KDE and other Linux desktop projects make things more Windows-like. Windows might get some things wrong, but there is also a lot that it gets right. Real respect for the user is fixing the geniune problems with the interface he's accustomed to, not making things different for the sake of being different or for some abstract design principles. I think Tog said it best in discussing the differences between Windows and Macs:

Consistency is a funny thing. The most important area of consistency is the area most people don't even think about; which is why it is the most important area. What am I talking about? Shortcut keys. Button ordering. And all those other little things users learned way-back-when, soon absorbed into habit, and never considered again. The way a lot of these work is backwards in Windows. No, let me correct that. It was backwards in Windows, until Windows hit a 90% market share. Now, it is backwards in Macintosh.

No zone => Windows script-foo

pageer@skepticats.com (Peter Geer)

It's been a very "IT" kind of afternoon.

I started out the morning well, got some coding done, and was in "the zone" up until about 10:50. The then fire alarm went off. I don't know why, because there wasn't any major fire. Maybe it was a drill/test, maybe some kid pulled the fire alarm. Who knows.

Anyway, I had to go stand outside in the unseasonably cold weather (it's in the 30°F range this week) for about 10 minutes. That sapped a great deal of my motivation. Then I had to stand in line for another 10 minutes while the guards checked IDs put people through the metal detector. That pretty much knocked me out of the zone for the rest of the day.

So this afternoon was devoted to Windows XP trouble-shooting, because it's reliatively brain-dead. I worked with a laptop user to finally track down a long-standing error message that had been showing up in one application. And by "track down" I mean I finally got to actually see the error message and quickly diagnosed it as a file permission problem. I would have done that a long time ago, except that these laptops have no connectivity to our network and are almost never available at a time and location where I can look at them. Plus nobody ever bothered to tell me the exact error message, which makes it a little harder to figure out what's going on. While I try to keep my skills sharp and up-to-date, I have to admit that I'm still woefully lacking in the telepathic debugging department.

Now that I've got that problem tracked down, I'm presented with another. This problem affects 20 odd laptops. How do I fix it on all of them without having to go around and physically touch each of them? Remote access is out, so the first obvious solution is to get the users to do it. However, that won't work because I can't give them the admin password. The second obvious solution is to pawn it off on the help desk, but they'd never go for that. After all, we operate on the "whoever touches it first is stuck with it forever" theory of assigning support tasks. Hardly an optimal algorithm, but that's the way it is and nobody with any power is willing to rock the boat.

That leaves me with one option: script that sum bitch! I might not be able to trust the users with complex instructions, but I can certainly trust them to dump some files on a flash drive and double-click an icon.

The only problem is administrator access. The Windows runas command prompts for passwords. I need something that can use a stored password from a batch file, preferably one kept in an encrypted file. Luckily, a little Googling turned up just such a tool: lsrunase. That looks like it should do the trick. Another quick Google for a Windows command reference to find the CACLS command and I should be good to go. All I need to do now is write the batch file and test it out on one of the laptops. But that'll have to wait for tomorrow.

Blind, raging Windows hatred

pageer@skepticats.com (Peter Geer)

You ever have one of those moments when you almost wish you could string Bill Gates up with his own entrails? I had one of those moments yesterday morning.

My problem was not Bill Gates or even Microsoft in general, but their representative to the common man: Windows XP. I was bitten by that annoying Explorer bug where it blocks for several seconds at a time for no particular reason. I had to clean off my D: drive because it's is a measly 30GB, which is just barely enough to house the data I've accumulated over the last five years, plus my collection of virtual machines. However, it seemed like every two minutes, when I clicked something, explorer would lock up. No apparent reason, no inordinate disk or CPU activity - it just stopped responding. Then, after 5 to 20 seconds, it would pick up where it left off.

Now, this has happened many times before, but never quite so often in one session. It was positively maddening. It's a good thing I was drinking decaf, or I probably would have ripped my monitor to pieces.

Things went slightly better today, but I did have an issue with deleting a file. Basically, the progress dialog displayed for way, way, way too long. Like a minute or two for a 1MB file. It's just ridiculous.

The worst part is, it's not like I can just stop using Explorer. If this were a UNIX, I could just switch desktops or file managers. But on Windows, that just doesn't work.

Oh, don't get me wrong - there are alternative shells and file managers, but I've never found any of them to be very good. At least not the free ones (I haven't tried any of the paid-for options because my boss is kind of cheap). Most of the free file managers seem to focus on useless features like dual-panes and integrated file viewers (that's why we have file associations - duh!). And the third-part shell replacements...they just feel like second-class citizens. Plus I've found that things tend to break when Explorer isn't running.