Writing Portable Scripts in WSH
(Page 1 of 4 )
If you’ve ever had to move one of your scripts to another machine, you may have run into a little problem. Every machine can be set up differently. This can pose a problem to administrators. This article describes how to avoid the most common pitfalls.
The problem arises due to the fact that most people write environment specific scripts. Using full path names and assuming certain programs are installed are just two of the very common mistakes that script writers can make.
If you plan on using your script on more than one computer, using full paths should be considered a big no-no. The most common example of this mistake is assuming that Windows is installed in the C:Windows directory.
Sure, it’s logical to believe that the majority of users will install Windows XP to its default location, but let’s not forget that a great number of systems running XP were upgrades from Windows 2000. Windows 2000 systems were installed to the C:WINNT directory by default.
But wait! Who’s to say that the user is even running Windows XP? I know a great many people running Windows Server 2003 and Windows Vista. My point is that you need to know your target audience, and if you don’t, you need to be prepared for anything.
Windows provides a simple method to programmers for ensuring platform compatibility. Every Windows system provides environmental variables. These unique variables provide specific information about the current Windows installation.
As an example, the %windir% variables will return the directory where Windows is installed. Another example is %homepath% which returns the user profile location for the currently logged on user. Let’s take a look at the default environmental variables.
Variable | Description | Sample Value |
%systemdrive% | System drive letter | C: |
%systemroot% | System root directory | C:Windows |
%systemdirectory% | The folder in the system root that contains the system files | C:WindowsSystem32 |
%windir% | The “Windows” folder | C:Windows |
%programfiles% | The Program Files directory | C:Program Files |
%comspec% | The command line interpreter | C:WindowsSystem32cmd.exe |
%temp% | Current temporary files directory in 8.3 format | C:DOCUME~1UserLOCALS~1Temp |
%homedrive% | Drive letter associated with the current user | C: |
%homepath% | Path to current user profile | Documents and SettingsUser |
%homeshare% | Path current user’s share | |
%os% | OS generation | Windows_NT |
%computername% | The current machine name | COMPUTERNAME |
%userdomain% | The machine or domain that contains the current user’s account | COMPUTERNAME |
%username% | Current user | User |
%path% | The program execution path | C:Windows;C:WindowsSystem32 |
%allusersprofile% | All Users profile location | C:Documents and SettingsAll Users |
%appdata% | Application data storage | C:Documents and SettingsUserLocal SettingsApplication Data |
%cd% | Current directory string | C:Documents and SettingsUser |
The above list of the most common environmental variables is not complete. There are user specific, hardware specific, and application specific variables as well. For example, %NUMBER_OF_PROCESSORS% will return the number of processors currently installed on the machine.
Environmental variables can differ to some degree between Windows versions, but the majority of common ones always stay the same. You can see what an environmental variable contains by echoing it from the command line, e.g. “echo %systemroot%” without the quotes.
For a more complete list of environmental variables available to Windows XP, you can read the Windows XP Professional Product Documentation on the Microsoft website.
Next: Scripting Environmental Variables >>
More Windows Scripting Articles
More By Nilpo/Developer Shed Staff Writer
