June 2006


One of the annoyances that Win32 Perl bothers me with is the lack of traversing the PATH. There are some Win32 specific functions built in such as Win32::GetFullPathName() and Win32::ExpandEnvironmentStrings() which are very useful when dealing with Windows’ paths, but suck when dealing with a PATH relative file.
For example, if you have a path like "rundll32.exe" there is no way for Perl to easily determine that this represents c:\Windows\System32\RunnDll32.exe. This should be pretty simple to do since "%SystemRoot%\System32" listed in the PATH variable by default. The closest Win32 Perl comes to solving this is to use Win32::GetFullPathName(), but this would prefix the file with a path based on the current working directory (from Win32::GetCWD()), not traverse the PATH looking for a file match.
It is too bad that there isn’t a simple solution to this. However, until the day when such functionality is added to Win32 Perl you can use the script in our Perl Script Repository called FindInPath.pl which does traverse the PATH looking for files: http://www.roth.net/perl/scripts/scripts.asp?FindInPath.pl

We have redesigned our site a tad bit by adding forums. It is a place for open conversation and discussions. You can post thoughts, start threads, expose conspiracies, float new ideas…do what comes naturally in a forum! :)

Unfortunately registering for the Blog does not register you for the Forums–you’ll need to register twice. Once things settle we may try to resolve that. Give it a try and let us know what you think:
http://www.roth.net/forums/

Dave’s latest Windows Scripting Solutions article (link) demonstrates how a Perl script can use UPnP to query Internet Gateway Devices (IGD) to see what ports have been mapped.

It is unfortunate that UPnP support is haphazardly implemented on most vendor’s IGDs (such as broadband routers). This means that even the best written UPnP client code can only view the mapped ports that the IGD allows it to view. The promise of IGD falls quite short in this regard since not only are many of the features in the various DCPs optional but how they are implemented are up a vendor’s interpretation. Hopefully newer technologies such as Web Services on Devices (WSD) based on the Devices Profile for Web Services (DPWS) can change that.

To read this article requires a subscription to Windows Scripting Solutions.