On Sat, Jan 29, 2005 at 05:44:20PM -0600, Craig A. Berry wrote: > That was my first theory as well, but that's not it. It's the result of > the fact that I have a logical name "bin" defined, so it looks for > bin/foo there rather than in the local relative path. Simply prepending > ./ seems to do the trick: > > $ show logical bin > "BIN" = "gnu:[bin]" (LNM$SYSTEM_TABLE) > > $ perl -e "open(F,qq/<$ARGV[0]/) or die qq/$!/;" bin/chown > $ > > succeeds because chown does actually exist in gnu:[bin] > > $ perl -e "open(F,qq/<$ARGV[0]/) or die qq/$!/;" bin/instmodsh > no such file or directory at -e line 1. > %RMS-E-FNF, file not found > > fails because instmodsh does not exist in gnu:[bin] > > $ perl -e "open(F,qq/<$ARGV[0]/) or die qq/$!/;" ./bin/instmodsh > $ > > succeeds because the additional syntax disambiguates it. We had to do > something like this to File::Find some time ago. > > Do you want a patch to cp_if_diff in Manifest.pm or do you already have > an idea of how you want to handle this?
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. 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.
