Windows Path Variable: Run oStress From Any Folder

The Windows Path variable is a list of folders that Windows searches when you type the name of a program.

Why oStress Needs It

A DBA at a client was reading the oStress posts and noticed a chore. Every time the tool was needed, they had to change to the RML Utilities folder first. They wanted to type the program name from any folder instead. The trick is to add that folder to the Windows Path variable, once.

The same trick works for sqlcmd, bcp or any other command-line tool. The first post of the series uses oStress from its own folder. See oStress Load Test: Run Many Sessions Against SQL Server. After this change, it runs from anywhere.

See How Windows Finds a Program

When you type a name, Windows looks through the folders of the Path variable from first to last. The first match wins. You can ask PowerShell where a name resolves. This command shows the location of sqlcmd.

Get-Command sqlcmd | Select-Object -ExpandProperty Source

On the test PC, the answer is a SQLCMD.EXE under Program Files, in the Client SDK folder. Your path will differ with the version of the tools. A name that isn’t in any Path folder gives an error instead.

Try It for One Window First

Changing the Path for good affects every new window. Try the idea on a harmless program first. This block creates a small command file in a temporary folder and tries to run it. Then it adds the folder to the Path of the current window and runs the file again.

$tools = Join-Path $env:TEMP 'PathDemoTools'
New-Item -ItemType Directory -Path $tools -Force | Out-Null
Set-Content -Path (Join-Path $tools 'pathdemo.cmd') -Value '@echo Found it from any folder.'
try { pathdemo } catch { $_.Exception.Message }
$env:Path += ";$tools"
pathdemo

The first call fails, because Windows doesn’t know the folder. After the folder joins the Path, the same name works. This is the output.

The term 'pathdemo' is not recognized as a name of a cmdlet, function, script file, or executable program.
Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
Found it from any folder.

The change lives only in that window. Close the window and it is gone. This block removes it at once and deletes the demo folder.

$env:Path = ($env:Path -split ';' | Where-Object { $_ -ne $tools }) -join ';'
Remove-Item -LiteralPath $tools -Recurse

Make It Permanent

To add a folder for good, open the Start menu and search for Edit environment variables for your account. In the Environment Variables window, select Path under User variables, choose Edit and then New, and paste the folder. Press OK in each window. A change to the user variable needs no administrator rights. The same steps under System variables change the Path for every user, and they need an administrator.

PowerShell can do the same job. This block reads the user Path and adds the RML Utilities folder if it isn’t there yet. Then it writes the list back. It changes your Windows settings, so run it only when you want that. If your user Path holds entries like %USERPROFILE%in, this block turns them into fixed folders. Use the Environment Variables window in that case.

$folder   = 'C:\Program Files\Microsoft Corporation\RMLUtils'
$userPath = [Environment]::GetEnvironmentVariable('Path', 'User')
$entries  = @($userPath -split ';' | Where-Object { $_ })
if ($entries -notcontains $folder) {
    [Environment]::SetEnvironmentVariable('Path', (($entries + $folder) -join ';'), 'User')
}

The undo removes the same folder. It reads the folder name from the block above. Run it in the same session, or set the folder again.

$entries = @([Environment]::GetEnvironmentVariable('Path', 'User') -split ';' | Where-Object { $_ -and $_ -ne $folder })
[Environment]::SetEnvironmentVariable('Path', ($entries -join ';'), 'User')

After You Add It

Open a new window. Windows hands a copy of the Path to every program when it starts. A window that was already open keeps the old list. A new tab in an open terminal app keeps it too. Close the whole app and open it again. Command Prompt reads the same Path, so the steps work there too.

In the new window, type ostress and the tool’s help appears. Get-Command ostress shows the folder it came from. The tool installs under Program Files, in a Microsoft Corporation folder named RMLUtils, on most machines. If the name is still not found, check the spelling of the folder. Make sure it holds the program file itself, not a subfolder.

Keep the Path Clean

A long Path collects dead entries over the years. This command lists every folder in the current Path that no longer exists. It prints nothing when the list is clean.

$env:Path -split ';' | Where-Object { $_ -and -not (Test-Path -LiteralPath $_) }

Three more rules help. Add a new folder at the end, so it can’t shadow a system tool. Don’t use the old setx command for the Path, because it can cut a long value at 1,024 characters. And add only folders you trust. A folder that other people can write to lets someone drop a fake program with a familiar name.

You could argue that scripts should always use full paths. For scripts that run on other machines, that is right. A full path leaves nothing to chance. The Path variable is a convenience for your own prompt. There, typing the whole folder every time costs more than it protects.

What to Remember

The Windows Path variable decides which folders Windows searches for a command. Test a change in one window, then add the folder to your user Path. Open a new window and verify with Get-Command.

The Windows Path variable is not a setting for programs, it is a shortcut list for you.

Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.