mech-dump (part of Perl WWW::Mechanize) is incredibly stupid about it's input file name

If the file name it is dumping does not end in:

.html

the mech-dump will spit out an error that the file content is not text/html it is text/plain. And of course, it immediately quits without doing anything helpful.

And then you go and look inside the file, and this is right at the top:

content="text/html"

You ask yourself What the Hell?

It’s a terrible error message; that’s the hell of it. The error message should say “Input file name does not terminate with the string .html”

I use Linux a lot, and in Linux, files do not have to have file extensions in their names. Over in the Windows side, it is expected that a file name has an extension. Windows uses that file name extension to figure out which program should be associated to the file type. But in Linux, the program association data is written inside the file itself.

This has two effects. First, files in Linux don’t need file extensions in their name. Second, you can name a file in Linux to not have the file extension, and the file works anyway.

So, if I’m writing a Perl script on Linux and I want to dump out something I’ve just pulled down from a web server, using WWW::Mechanize, I might be inclined to name the file where I’m dumping this web form to www_mechanize_web_form_dump

And this would be a mistake, because when I later run

mech-dump www_mechanize_web_form_dump

I’m going to get spit at with the message that the file does not contain HTML, it contains only plain text.

It would have saved me a bunch of time, if the error message would have been “mech-dump does not interpret files with names that do not end in .html”

That might seem kind of a silly input file name constraint, but at least the error message wouldn’t be misleading.

Strawberry Perl did a brain-dead thing to me

When one installs Strawberry Perl, one gets a file structure that has a directory named “site”. Underneath “site” is “bin”.

But of course, there is also a “bin” directory where the perl.exe is stored too. Why wouldn’t you store your source code in the bin directory with the perl.exe? If you are in that directory at the command prompt, perl.exe doesn’t have to do any searching to find your Perl script.

Somewhere along the line, I was told “Don’t put your source code in the bin directory where perl.exe is stored. An upgrade will come along, and delete everything in the directory where perl.exe is – including your source code! Put your scripts in ../site/bin because that won’t get wiped out during an update of perl.exe”

And, I just upgraded Strawberry Perl, and it wiped out everything.

Yes: including the ../site/bin directory dedicated to being my safe place for my source code! It’s the place (that was supposed to be) protected from accidental-upgrade-based-deletion.

Just “bin” – expect everything there to be wiped, when an upgrade happens. But “../site/bin” – the whole reason we have this extra folder structure is because there should be a place for your code that doesn’t get clobbered during an upgrade.

And Strawberry Perl clobbered it anyway.

Sigh. This make me really leery of trying to make scripts I could distribute to my users. Should we need to push an upgrade to Strawberry Perl, if someone had written their own scripts, we would clobber their work! Gah!

Microsoft is Pinky

“Brain: It must be inordinately taxing to be such a boob. Pinky: You have no idea.”

I have an application I’d like to run on Windows 10, that invokes the UAC (User Account Controls) every time it runs. I’d like to turn off UAC for just this one program.

Nope. No can do

(BTW, I really wanted to link to a clip from Pinky and The Brain, for “Brain: It must be inordinately taxing to be such a boob”, but Youtube / Google gets completely hung up over that word “boob”)

The obvious first step is to change the shortcut to launch the .exe to “Run As Administrator”. Doesn’t work.

There is an article in the Microsoft support forums that says one can configure Windows to run a chosen program without invoking the UAC. It involves downloading their Accessibility Toolkit, which allows Windows to be altered for people with muscular dystrophy (for example). Stupid extra keystrokes for people who have a hard time manipulating a keyboard can be done away with, which is a good thing.

And if Microsoft can’t figure out how to suppress the UAC for the one program for regular users, well, maybe us regular users can shoe-horn the accessibility toolkit into getting Windows to be helpful instead of annoying.

Nope. Doesn’t work. The program I reconfigured does now have an updated icon, to indicate that UAC will be invoked when I want to run it. But all I wanted was to click the icon, and the program works.

My choice is now between “turn off UAC completely” or “every time I run this program, get stopped and slapped in the face with the reminder of how bad at programming Microsoft is”.

Well, I’ve learned that sometimes, it’s better to be happy than to be right, so UAC is getting turned off, system-wide. It’s stupid.

Microsoft is such a boob.