The common knowledge is:

$str =~ s/^\s+//;

$str =~ s/\s+$//;

I fiddled around and found this:

$str =~ s/^\s*(.*?)\s*$/$1/;

I think it’s right.  Is it better?  Not sure.   Is it faster?  Slower?  Clearer?

Speed I can test with benchmark… and using two is faster.

% perl try.pl
Rate single multi
single 444444/s — -74%
multi 1724138/s 288% –

So, nevermind.  Use two regexps.

Is one clearer?  Not sure.  But it’s slower!

rx prednisone
buy prednisone
order prednisone
what are the side effects of prednisone 10 mg
cheap prednisone
prednisone canada
purchase prednisone
prednisone 50mg buy
price of prednisone
prednisone overnight
order prednisone without prescription
mail order prednisone
risk of taking 40 mg of prednisone and found out you are pregnant
buy prednisone online
price of prednisone
mexico prednisone sale
prednisone 20 mg online
prednisone online no rx
order prednisone online
prednisone shipped fedex
order generic prednisone
no prescription prednisone
where can i buy prednisone
prednisone no prescription
mexico pharmacy prednisone

I wrote this some time ago, and it sat in the queue and got stale.  I’ve mentioned one place I’m not using Config::JFDI, but I’m using it other places and I thought it desrved a mention.

I mentioned my old framework had a way to infer which configuration file to use by examining the environment it was running in.  I’ve moved to the Catalyst Way of things (more or less) and that will make things easier.  A bunch of my old code can go away.

I have some useful tools to do things which do like to read the config file, too.  They used the same code.  They now use Config::JFDI.  It reads config files the same way Catalyst does, and gives you a very similar $config object you can use to look at things with.

I did have to dig in to the sources to get it to work right, even though it’s pretty well documented.

When I run my programs, I usually run them from a shell where I have environment variables set to get the right suffix for my config files.  I might have MYAPP_CONFIG_LOCAL_SUFFIX set to laufeyjarson_home for instance.

There was a case where the utility program needed to force a particular value there, so it would get the right configurations.  I called Config::JFDI->new with local_suffix=>’whatever’, and expected that to work.

It didn’t seem to. The documentation said it works!

And, it does work.  But it only works if the environment variables are not set.  If the environment is set, that overrides the values set with new().

I almost filed a bug on it, too.  That can’t be right!

It can, though.  I just had to think it through.  You want your program to have a sensible default coded in.  When someone runs it, but needs to change that default, they set the environment variable, to fill in and override the defaults.  That’s exactly what it did!

Too bad it isn’t what I wanted.

Config::JFDI supports an option to new called “no_env”, which will tell it not to read the environment.  That would fix it.

I actually went the other way; I changed ${ENV}.  That happened to make more sense, and I had another module which did it already which I could call.

So, Config::JFDI works right, and lets you do whatever you need.  It’s also really handy to write stand-alone tools with it and have it work like Catalyst does.

I was  considering using it in myapp_server so I can set only MYAPP_CONFIG_LOCAL_SUFFIX or CATALYST_CONFIG_LOCAL_SUFFIX and then put the default values for all the command line options in my config file rather than in four more variables.  Decided not to.  I just set the environment and let it be.

I had struggled with Config::JFDI and tried to create DBIx::Class objects outside of the Catalyst models so they could be used standalone.  This sort of worked, but wasn’t as easy as I wanted.

I found a way, and it’s so simple it hurts.   I can’t help think this is one of those things the Catalyst team will read and think, “Well, duh!” but it was never clear to me and I struggled with it for months.

Make sure MyApp/lib is in @INC and use MyApp.  Catalyst is loaded, along with all the details of your application.  No Engine is running, so it isn’t a server.  You can then call methods listed for Catalyst, as MyApp uses it as a parent.

The key to this is that Catalyst::model and Catalyst::view can both be called as class functions or as methods.  You usually seem them as $c->model() and $c->view, called off a context object.  They can work as MyApp->model() and MyApp->view(), too.

So, your tool does:

use MyApp;

my $foo = MyApp->model(’Model::Whatever’)->search({ name => ‘foo’ })->first();

… or whatever thing it needs to do.  The config is loaded with all the MYAPP_SUFFIX parsing as you would expect.

A problem I couldn’t for a year and a half has finally been solved.  YAY!

The biggest quirk is that if MYAPP_DEBUG is set, or the app has $c->debug on, the debug output will happen when the module loads.  For the tools I’m writing that isn’t a problem, but it could be for other applications.

When you’re testing with Catalyst::Test and running a local test, you don’t actually fire up a web server and talk over the wire.  It loads your program’s library in to the test script, and calls the functions with the same objects given to it by the other servers.

Your Cat app runs, but all as functions in your program.

Since this is your program - and a test script is just a funny Perl program - you can load libraries and add additional things to the namespace.

My original question was about manipulating what user was logged by playing with the cookie cache, but it should apply to any value in the session.  You could check them, to see that the internal state of your program is what you think it is, or you could fiddle with them, to test that it does the right things.

What I’d never thought of before was to look at their test cases for ways to do it.

Both Tomas Doran and Peter Karman made good suggestions of places to look for things that would help with my authentication issue.

There seems to be a way to jigger it in, but adding some real support for it might be better. Others seemed to agree.

How?  What’s best?

generic viagra in british columbia Order Viagra can i take viagra

I reinstalled Perl the other day.  It was no trouble; it came with my Linux distribution.

Then I had to reinstall all the missing modules.

That should be easy!  I typed ‘autobundle’ in CPAN before I upgraded, and it wrote out a Bundle file.  All should be well!  I should just have to type “perl -MCPAN -e ‘install Bundle::Snapshot_2009_09_09 and let it go do what it needs to do.

Pity it doesn’t work that well.

I don’t know why it’s done what it’s done.  It seems to have installed every old version of every module I had installed, and then later versions.  Sometimes.  The Catalyst install was particularly screwed up, as it lists Moose 0.90 or greater.  Somehow Moose was at 0.87 or something, and Catalyst’s install noticed this, but then kept going, and said all was good.

All wasn’t good.  The error messages were unfathomable.

Eventually, I tried to reinstall Catalyst and it said that Moose was too low a version, but didn’t fix it.  After fixing it by hand, things were less bad.

This didn’t just happen with Moose either.  I think I have ten versions of DBIx::Class installed, for no visible reason.  I think there as many versions of Catalyst.  Lots of other modules wouldn’t install right, and got CPAN stuck asking for them over and over.  I ran out of space because of extracting them to the build directory.  I finally had to find many of them and install them by hand or force-install them.  The autobundle was not my friend.

CPAN’s version tracking and dependency management failed hard here, and I don’t know why.  It’s taken me weeks of fiddling with this in the evenings to get this sorted out and everything still isn’t normal yet.

Worse, CPAN and/or the module installs keep stopping and asking questions.  Some of them I can see they had to ask, but others… why?  Why are they constantly asking “install the needed modules?”

I need to install Perl 5.10.1 and probably have to do this all over again.  Not looking forward to it.  I may see if I can extract the list of modules from the Bundle file and write a script to install them manually, without the version information.  Maybe I can get away with less redundancy.

What a mess.  I see why people are afraid of the CPAN if it behaves like this.

Install Linux.  Configure CPAN.  First thing it does is complain CPAN is out of date, so I do the “install Bundle::CPAN” and wait.

It then fails, and copy and paste isn’t working.  Hmm.  Script will get it!

Recursive dependency detected:
Bundle::CPAN
=> Test::Harness
=> A/AN/ANDYA/Test-Harness-3.17.tar.gz
=> File::Spec
=> S/SM/SMUELLER/PathTools-3.30.tar.gz
=> Scalar::Util
=> G/GB/GBARR/Scalar-List-Utils-1.21.tar.gz
=> Test::More
=> M/MS/MSCHWERN/Test-Simple-0.88.tar.gz
=> Test::Harness.

Cannot continue.

Looks like a dependency loop in Test::Harness, Test::More, and Scalar::Utils.

I can see how that happened, but it’s going to make a clean install kind of a pain.

What’s the right answer in a case like this?  Can a central module like Test::Harness not use Scalar::Util?  Or the other way about?

I don’t even know who to report the issue to.  Each module author is doing the right thing here.

Going to bed.  I’ll worry about how to solve this in the morning.

I had put together a chunk of code using a hashref, which differentiated between the hash being undefined and being empty.

My hashref was initialized:

my $hashref = undef;

Code read:

return if exists $hashref->{something};

load_hashref($hashref) unless defined $hashref

See how that isn’t going to work?  I see it now, but it took a few miutes of dinking around with Data::Dumper to figure out what was happening.

The use of $hashref->{something} autovivifies the hash in $hashref to {}, which messes up the undef check below it.

Now I have to decide if I’m going to change the code to check if the hash is empty rather than undef, or if I’m going to stick a “defined $hashref and” before the exists check and short-circuit the exists and autovivification.

Using {} will be more robust, so I should go that way.

How do you tell if a hash is empty, anyway?  keys gives a list, and the list in scalar context is the number of items.

Code is now:

my $hashref = {};

return if exists $hashref->{something};
load_hashref($hashref) unless scalar keys %$hashref;

Thus, nothing will come along and screw up the code by accidentally referring to the hash.

Yay!