> On Feb 21, 2017, at 1:47 PM, Matt S Trout <mst@shadowcat.co.uk> wrote: > > Also, if a do() user doesn't check $@ - and most don't realise to - they won't > even see the "Can't find" error. Wow! I assumed it would die. But it's even worse. $@ appears to be empty. I think you have to check $! for do. $>perl -E' do "foo.pl"; say "$!"' No such file or directory > 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. I'm good with the idea of warning. To me, I'd prefer it die like require does. There's a related precedent we've already done which is to die if one of the items in @INC is inaccessible due to permissions, we die rather than skipping the path. > 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*. Given do doesn't even emit to $@, I'd say their code was fragile to begin with but fair point. ToddThread Previous | Thread Next