Application name 'dpath' conflicts with Windows shell command

[mjcarman]

In Windows, the name 'dpath' conflicts with a built-in shell command of the same name.
cf. http://ss64.com/nt/path.html

[renormalist]

Haha, funny, "DPATH is an undocumented internal utility" - my naming skills are amazing. :-)

Seriously, can you explain what actually happens with my dpath tool on Windows?
Which one wins, the internal tool or my one? Or does it throw an error when executing or installing it?

Do you have a suggestion what to do about it?

[mjcarman]

I like the name. Unfortunately, it's hard to avoid colliding with any built-in on any platform; especially esoteric undocumented ones.

App::DPath installs cleanly on Windows once you apply labrown's patch. The test suite invokes dpath as perl -Ilib bin/dpath, which avoids the name conflict.

On Windows, built-in shell commands take precedence over executables of the same name found on the path. In this case it looks like nothing happens when running dpath. There's no error, no output of any kind. What actually happens is that it sets the DPATH environment variable. e.g. Running dpath "/foo/bar" baz.yaml results in the DPATH variable being set to "/foo/bar" baz.yaml.

You can work around the conflict by specifying the path to the script (e.g. C:\Perl\site\bin\dpath.bat or perl C:\Perl\site\bin\dpath) but that's to verbose to be useful. I ended up renaming the script to "ddpath." (I'm not recommending that name; it was just a quick work-around.)

I think the only solution is to use a different name -- at least on Windows.

[renormalist]

Resuming while having a break during vacation...

Do you know how to install a script with a different name ("ddpath" or "appdpath") depending on OS? I'm happy to take patches.

Thanks.

[dolmen]

@renormalist This requires a .PL file to fill blib/bin/ at build time. See PL_FILES in ExtUtils::MakeMaker.

[karenetheridge]

can PL_FILES be used to transform EXE_FILES, though?