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

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

Thread Previous
Sawyer X
October 24, 2016 19:05
Re: Provide -Dfortify_inc Configure option to remove . from @INC
Message ID:

I just want to clarify something here. The point mst has raised here
(okay, I raised, but *he* found it!) is to just add this to the total
facts that we know of possible problems we might need to deal with. It
isn't to prevent this patch or even delay it. It's to add more to the
issue, rather than pause the issue.

The idea was to allow testers (and mainly the toolchain) to vet this
change. We can still apply the patch and continue.

However, and I think mst is trying to move forward in that direction in
this email, perhaps there is something to improve (beyond this patch) to
help with this problem that might come up.

On 10/22/2016 07:42 PM, Matt S Trout wrote:
> 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.

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