On Sun Nov 27 04:33:08 2011, smueller@cpan.org wrote: > On 11/26/2011 07:19 AM, Father Chrysostomos via RT wrote: > > On Fri Nov 25 17:16:21 2011, jkeenan wrote: > >> On Thu May 05 09:15:22 2011, nickl@ebi.ac.uk wrote: > >>> Multiple changes to $ENV{TMPDIR} are not reflected by File::Spec- > >>> >tmpdir() because it caches the result on the first call. > >>> This is a problem if the value of $ENV{TMPDIR} changes during the > >>> lifetime of the script - especially problematic for scripts running > >>> in a persistent environment such as mod_perl. > >>> > >> > >> Confirmed -- but could it be argued that if a program is to be run in a > >> persistent environment, and then you change that environment in > >> mid-course (which is what redefining %ENV entails), you get what you > >> deserve? > >> > > > > You could, but then one could argue back that modifying env vars > > throughout a program is common practice. (At least I had to write ten > > lines to juggle various env localisations recently, because LWP and > > Net::SSL were refusing to play along nicely without that.) I think I > > agree with the original report. A module shouldn’t change behaviour > > (stop reading %ENV) depending on whether you’ve used a function in it > > before. > > Not that I disagree, but at the same time, we've seen many people > complain about the dismal performance of some File::Spec operations. > Maybe this is a case where attempting to cache things for performance > went wrong? Maybe it even matters. > > Just something for consideration. File::Spec could do with some love > that I can't give it. It’s possible to have the best of both worlds: cache the tmpdir, but check whether the environment has changed before returning it again. I have implemented this in commit 82730d4. (I only thought about smoke-me after pushing this to blead. I don’t think it’s worth a revert because of that. We’ll see what happens. :-) -- Father Chrysostomos --- via perlbug: queue: perl5 status: open https://rt.perl.org:443/rt3/Ticket/Display.html?id=89940