At work, we have a setup where our product's source code is mounted to a drive letter, and if you want to have different builds, you have different drives. The build tools are reached by adding something like "/Trunk/bin" to the PATH, so no matter which drive you are in, you use the tools for that build. This works fine in cmd.exe, however, this doesn't work in Powershell. Is there a Powershell compatible way to accomplish this?

EDIT: As requested, here is the result of $env:PATH in Powershell, with my username subbed out for a pile of eeeeeeee

C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\CommonExtensions\Microsoft\TestWindow;C:\Program Files (x86)\MSBuild\14.0\bin;C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\;C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN;C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\Tools;C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319;C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\VCPackages;C:\Program Files (x86)\HTML Help Workshop;C:\Program Files (x86)\Microsoft Visual Studio 14.0\Team Tools\Performance Tools;C:\Program Files (x86)\Windows Kits\8.1\bin\x86;C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.1 Tools\;C:\Applications\Cmder\bin;C:\Applications\Cmder\vendor\conemu-maximus5\ConEmu\Scripts;C:\Applications\Cmder\vendor\conemu-maximus5;C:\Applications\Cmder\vendor\conemu-maximus5\ConEmu;C:\ProgramData\Oracle\Java\javapath;C:\Python27\;C:\Python27\Scripts;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\Windows\CCM;C:\Program Files (x86)\Microsoft ASP.NET\ASP.NET Web Pages\v1.0\;C:\Program Files\Microsoft SQL Server\110\Tools\Binn\;C:\Program Files\Microsoft SQL Server\130\Tools\Binn\;C:\ProgramData\chocolatey\bin;C:\Program Files\dotnet\;C:\Program Files (x86)\Microsoft SQL Server\110\DTS\Binn\;C:\Program Files\Microsoft\Web Platform Installer\;C:\Program Files (x86)\Windows Kits\8.1\Windows Performance Toolkit\;C:\Program Files (x86)\Microsoft Team Foundation Server 2015 Power Tools\;C:\Program Files (x86)\Xoreax\IncrediBuild;C:\Program Files\Microsoft SQL Server\Client SDK\ODBC\110\Tools\Binn\;C:\Program Files (x86)\Microsoft SQL Server\120\Tools\Binn\;C:\Program Files\Microsoft SQL Server\120\Tools\Binn\;C:\Program Files\Microsoft SQL Server\120\DTS\Binn\;C:\Program Files (x86)\Microsoft SQL Server\120\Tools\Binn\ManagementStudio\;C:\Program Files (x86)\Microsoft SQL Server\120\DTS\Binn\;c:\Program Files (x86)\Microsoft SQL Server\90\Tools\binn\;C:\Program Files (x86)\Microsoft SQL Server\Client SDK\ODBC\130\Tools\Binn\;C:\Program Files (x86)\Microsoft SQL Server\140\Tools\Binn\;C:\Program Files (x86)\Microsoft SQL Server\140\DTS\Binn\;C:\Program Files (x86)\Microsoft SQL Server\140\Tools\Binn\ManagementStudio\;C:\Program Files\Git\cmd;C:\Program Files\nodejs\;C:\Users\eeeeeeee\AppData\Local\Microsoft\WindowsApps;C:\Program Files\Microsoft VS Code\bin;C:_TFS\bin;N:\Tools;C:\Program Files (x86)\RabbitMQ Server\rabbitmq_server-3.5.6\sbin;C:\Users\eeeeeeee\AppData\Roaming\npm;\Trunk\bin;

  • Please post $env:PATH from within a powershell session where it does not work. – EBGreen Apr 11 '18 at 14:01
  • Change it to use explicit relative paths then it should work. So change \Trunk\bin to .\Trunk\bin – EBGreen Apr 11 '18 at 15:23
  • That didn't change anything. – Katherine1 Apr 11 '18 at 15:28
  • Hmmm...I was curious about this so I tested it. I added a path without the . and it would not find executeables. Then I added a path with it and it worked. What is the error that you are getting? – EBGreen Apr 11 '18 at 15:38
  • It says it is not recognized as the name of a cmdlet, function, script file, or operable program. Manually putting in Trunk\bin\command will execute the command as expected. Upon adding the ., the result of $env:PATH did not change regardless of restarting the shell or doing a refreshenv. – Katherine1 Apr 11 '18 at 15:41

Powershell treats "\" as a reference to the root of whatever context your operating from. So if you're working from the standard provider (e.g. "c:\") "\" is the root of C:. If you're working from the certificate store provider (e.g. "cert:") then "\" is the location container for the user and machine cert stores.

Another nuance to Powershell is the way it works with network resources. You typically experience greater success when operating from the file system provider (e.g. "filesystem:") than you do from the standard provider. You also have to specify the network location "\server\shareroot\etc". Your path variable needs to reflect either the mapped location (e.g. "Y:\Trunk\bin") or the network location (e.g. "\servername\folder\trunk\bin").

Hope this helps.

  • Not particularly, as it basically says there's no way to bring how things are done at work up to being fully compatible with Powershell easily. If I have to explicitly add every drive in use to the path, then I run into the problem of which set of build tools am I calling when I try to use them? I can't just revamp their entire build system. – Katherine1 Apr 14 '18 at 11:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.