The tricky issue of do()

Front page | perl.perl5.porters | Postings from February 2017

The tricky issue of do()

Thread Next

From:

Matt S Trout

Date:

February 21, 2017 19:47

Subject:

The tricky issue of do()

Message ID:

20170221194734.GA12583@newagaton.scsys.co.uk

Dealing with the fallout of removing '.' from @INC has been an interesting
exercise, but in the case of require()d files, I think overall a worthy one.

I'm rather less convinced about do().

In fact, I didn't until very recently realise that do() searched @INC, my
mental model of it had always been 'run this path and return the result',
and every piece of code I've seen in the wild that used it appeared to be
based on the same expectation.

Which means simply saying "welp, . isn't in @INC anymore" is going to leave
a vast number of broken scripts, most of them likely the ones whose users
are least knowledgable about perl (do 'config.pl' is very common baby perl,
I think).

Also, if a do() user doesn't check $@ - and most don't realise to - they won't
even see the "Can't find" error.

I'm not sure what to do about this - my best thought so far is to have a
warning that's emitted for "do 'file.pl'" where 'file.pl' exists in '.' but
not in @INC that recommends switching to "do './file.pl'". I think that's
better than 'apparently silent failure'. I don't know if there's a better
option still.

But I think lots and lots of people are going to have code that just
suddenly, silently, doesn't work, on the current path, and I think that's
something we should really try and address *somehow*.

Thoughts?

-- 
Matt S Trout - Shadowcat Systems - Perl consulting with a commit bit and a clue

http://shadowcat.co.uk/blog/matt-s-trout/   http://twitter.com/shadowcat_mst/

Email me now on mst (at) shadowcat.co.uk and let's chat about how our CPAN
commercial support, training and consultancy packages could help your team.

Thread Next