Tag: perl

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!