develooper Front page | perl.perl5.porters | Postings from October 2016

Re: Provide -Dfortify_inc Configure option to remove . from @INC

Thread Previous | Thread Next
Matt S Trout
October 22, 2016 17:42
Re: Provide -Dfortify_inc Configure option to remove . from @INC
Message ID:
On Sat, Oct 22, 2016 at 11:14:31AM -0500, Todd Rinaldo wrote:
> On Saturday, October 22, 2016, Matt S Trout <> wrote:
> > > Yes. The same goes for require since as best I can tell it's the same
> > underlying code. Is this a problem?
> >
> > 'do' is documented as "largely like: eval `cat`" and generally
> > used
> > as such - the fact that its support for files in the current working
> > directory comes via .-in-@INC is, I think, an implementation detail.
> You pulled cat from the docs the next line explicitly says that it
> does this based on searching @INC. In point of fact if was also in
> a library path, it would have the same surprising result of not loading the
> local file.

Yes, the next line says that it searches @INC, but, again, the mental model
that a normal user forms is that it's a relatively file loading thing that
*incidentally* also checks @INC.

Fundamentally, the documentation and the idiomatic usage as e.g.

  do '';

(which you'll find in tutorials all over the place) lead users to have a
different mental model for do() than require(), and I'm talking about the
feature from a user POV; the "same underlying code inside the VM" thing
isn't really the point here.

Note that I wrote this email because we've had multiple instances of
confusion on freenode's #perl channel due to this - the mental model thing
meant that even people who were aware of the .-in-@INC stuff didn't
immediately twig that was what was messing things up.

> >
> > So having do() suddenly fail to DWIM for its most common and documented
> > purpose is going to be intensely confusing, especially given its common
> > use for e.g. relative loading of config files in Olde CGI Scripts.
> I would argue the Olde CGI scripts using a shiny new perl they explicitly
> built to not have . in @INC should also be surprised if that works.

Most of the problems I've seen are not 'explicitly built' but instead
'user upgraded via package manager'.

> Note:
> all they have to do is change the code to 'do "./"' to get that
> intended result

True, and in the case of require() this is, at least to me, obvious, but
not so much for do(). Plus there's this slight problem where the world is
full of tutorials that use the idiom and we can't memory hole them all.

> The whole point of this change is that cwd should not be relevant to a
> running program's loading logic. It is my belief that do honoring @INC is
> consistent and correct.

I was more of the impression that the cwd should not be *accidentally*
relevant to a running program's loading logic.

What I'm pointing out here is a case where I believe that it was often
*intentionally* relevant. Honouring @INC is consistent to the internal
implementation but often, I think, not consistent to the intent of the user.

To come back to -

> Note:
> all they have to do is change the code to 'do "./"' to get that
> intended result

I wonder if it would be worth doing something like adjusting the error
message to make that more obvious. Something like

  Couldn't find '' in @INC (@INC contains: ...) - did you mean
  "do './'" ?

or similar might go a long way.

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

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

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About