On Tue, Feb 08, 2005 at 07:21:19AM -0600, Craig A. Berry wrote: > >I'm of half a mind to just say that having a logical called 'bin' is > >likely to break lots of unixy software if it makes "bin/foo" unsafe. > >I'm sure there's lots of other places in MakeMaker which use "foo/bar" to > >mean "./foo/bar" and something else will just break in the future. > > Well, File::Spec->catdir(File::Spec->curdir(), 'bin') seems to always > do the right thing.
I'm not going to rework the code so it translates foo/bar into ./foo/bar everywhere. Doing so in one place just covers up the problem. It will emerge again. > >In fact I'm a little surprised it hasn't. Could you check if it applies > >to C<open(F, qq/$ARGV[0]/)> as well? cp_if_diff() is one of the few places > >that uses < in open in MakeMaker. > > It does apply to other forms of open. I don't think it's shown up > before because it's relatively new to have a test in MakeMaker that > uses 'bin' as a directory name. But having bin as a directory name is very common. Unless convinced otherwise I'm considering this to be broken Unix->VMS path translation at the user end. The meaning of open(FILE, "foo/bar") is pretty clear, it should always be equivalent to open(FILE, "./foo/bar"). Since you can shut off the translation I'd recommend you do so. And that clears the decks for a release of _08.
