none
powershell does not recognize the path environment variable RRS feed

  • Question

  • Hi, I am running powershell in ws2012 r2 version and when i attempted to run executable whose path is defined in the env:path variable, it can not run. Here is the output. How do I make the path recognizable in powershell so I dont have to type full command. I hope and presume it is something very simple, but I am not able to find information regarding this online. Here is the output from dos prompt in which executable runs and loading of powershell after that executabe are no longer found:

    Microsoft Windows [Version 6.3.9600]

    (c) 2013 Microsoft Corporation. All rights reserved.

     

    C:\Windows\system32>signtool

    SignTool Error: A required parameter is missing.

    Usage: signtool <command> [options]

     

            Valid commands:

                    sign       --  Sign files using an embedded signature.

                    timestamp  --  Timestamp previously-signed files.

                    verify     --  Verify embedded or catalog signatures.

                    catdb      --  Modify a catalog database.

                    remove     --  Reduce the size of an embedded signed file.

     

    For help on a specific command, enter "signtool <command> /?"

     

    C:\Windows\system32>powershell

    Windows PowerShell

    Copyright (C) 2013 Microsoft Corporation. All rights reserved.

     

    PS C:\Windows\system32> signtool

    signtool : The term 'signtool' is not recognized as the name of a cmdlet,

    function, script file, or operable program. Check the spelling of the name, or

    if a path was included, verify that the path is correct and try again.

    At line:1 char:1

    + signtool

    + ~~~~~~~~

        + CategoryInfo          : ObjectNotFound: (signtool:String) [], CommandNot

       FoundException

        + FullyQualifiedErrorId : CommandNotFoundException

     

    PS C:\Windows\system32>

     

    Monday, October 13, 2014 5:56 PM

Answers

  • The Get-Command cmdlet may be useful.

    PowerShell does, indeed, use the Path environment variable. If you think signtool.exe is in the Path but PowerShell can't find it, then the most likely explanation is that you are simply mistaken.

    The most likely explanation your cmd.exe session can run signtool.exe is that the Path environment variable is not the same as it is in your PowerShell session. (This is assuming you're running cmd.exe and PowerShell on the same computer.)


    -- Bill Stewart [Bill_Stewart]

    Monday, October 13, 2014 9:55 PM
    Moderator

All replies

  • Hello,

    Verify :

    • Set-ExecutionPolicy (Unrestricted or AllSigned)
    • Imported Module (Get-Module -Listavailable)
    • PS Snapin (Add-PSSnap)

    Cordialement, Best Regards, مع أجمل تحياتي ESSALIFI Mohamed Faiçal [MCT-MCSE]. If your question is answered please mark the response as the answer so that others can benefit.

    Monday, October 13, 2014 6:26 PM
  • Add the path to your tools folder to the search path.

    You can view the current search path like this:

    $env:path

    Assuming signtool is in "C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Bin", do this:

    $ToolFolder = "C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Bin\signtool.exe"
    $env:Path = $env:Path + ";" + $ToolFolder

    That gives you easy invocation access to all the binaries in that folder.

    Monday, October 13, 2014 7:02 PM
  • Three answers - all wrong.

    The answer is that the tool is NOY in the path.

    $toolfolder in Alex' example is NOT a folder path.


    ¯\_(ツ)_/¯

    Monday, October 13, 2014 8:39 PM
  • The Get-Command cmdlet may be useful.

    PowerShell does, indeed, use the Path environment variable. If you think signtool.exe is in the Path but PowerShell can't find it, then the most likely explanation is that you are simply mistaken.

    The most likely explanation your cmd.exe session can run signtool.exe is that the Path environment variable is not the same as it is in your PowerShell session. (This is assuming you're running cmd.exe and PowerShell on the same computer.)


    -- Bill Stewart [Bill_Stewart]

    Monday, October 13, 2014 9:55 PM
    Moderator
  • To further complicate matters if you are running the CMD shell from Visual Studio or form the SDK the path is altered but only in that session not in all sessions.

    If the toll is in the immediate fold (because you copied there) then this will happen:

    PS C:\program files (x86)> cd  'C:\program files (x86)\Windows Kits\8.1\bin\x64'
    PS C:\program files (x86)\Windows Kits\8.1\bin\x64> signtool
    signtool : The term 'signtool' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a
    path was included, verify that the path is correct and try again.
    At line:1 char:1
    + signtool
    + ~~~~~~~~
        + CategoryInfo          : ObjectNotFound: (signtool:String) [], CommandNotFoundException
        + FullyQualifiedErrorId : CommandNotFoundException
    
    
    Suggestion [3,General]: The command signtool was not found, but does exist in the current location. Windows PowerShell does not load commands from the current l
    ocation by default. If you trust this command, instead type ".\signtool". See "get-help about_Command_Precedence" for more details.
    PS C:\program files (x86)\Windows Kits\8.1\bin\x64> .\signtool
    SignTool Error: A required parameter is missing.
    Usage: signtool <command> [options]
    
            Valid commands:
                    sign       --  Sign files using an embedded signature.
                    timestamp  --  Timestamp previously-signed files.
                    verify     --  Verify embedded or catalog signatures.
                    catdb      --  Modify a catalog database.
                    remove     --  Reduce the size of an embedded signed file.
    
    For help on a specific command, enter "signtool <command> /?"
    PS C:\program files (x86)\Windows Kits\8.1\bin\x64>
    
    


    ¯\_(ツ)_/¯

    Monday, October 13, 2014 10:51 PM
  • Read this very carefully:

    Suggestion [3,General]: Thecommand signtool was notfound,but does exist inthe current location. Windows PowerShelldoes notload commands fromthe current l ocation by default.
    Ifyou trust thiscommand,instead type ".\signtool". See "get-help about_Command_Precedence" formore details.


    PS C
    :\program files (x86)\Windows Kits\8.1\bin\x64> .\signtool


    ¯\_(ツ)_/¯

    Monday, October 13, 2014 10:53 PM
  • Make sure that your Path variable does not have any entry surrounded by quotes "" (such as "C:\Program Files (x86)\ Tools") - While cmd.exe has no issue with the quotes, PowerShell does not seem to understand them.

    Had exactly the same problem than you and removing the quotes worked like a charm.


    • Proposed as answer by CFSSF Monday, November 2, 2015 9:45 PM
    • Edited by CFSSF Monday, November 2, 2015 9:46 PM improved grammar!
    Monday, November 2, 2015 9:45 PM
  • Make sure that your Path variable does not have any entry surrounded by quotes "" (such as "C:\Program Files (x86)\ Tools") - While cmd.exe has no issue with the quotes, PowerShell does not seem to understand them.

    Had exactly the same problem than you and removing the quotes worked like a charm.



    path variable does not have quotes.  Read the posts to see what the real problem was two years ago.  By now the path has changed to the 2016 version of the path.  Remember that 2 years, according to Andy Grove, is two lifetimes for a computer.

    \_(ツ)_/

    Monday, November 2, 2015 11:40 PM
  • You saved me from hours of research to find the obvious. Even in Win10 powershell has same quirk. I can understand from a theory why a string is treated is as string and not as a path when quoted, but its not intuitive.

    Regards, Adarsha

    Sunday, September 4, 2016 12:18 PM
  • Quotes are only for a command-line parser. They cannot exist in an actual directory name. The directories in the Path variable must contain actual directory names. Quotes cannot exist in an actual directory name, so they should not appear in the Path variable.

    -- Bill Stewart [Bill_Stewart]

    Tuesday, September 6, 2016 2:53 PM
    Moderator
  • This can be caused by at least two things that "worked in DOS":

    1. Path elements that are quoted,

    2. Path elements that require %variable% expansion

    Which causes some pain with GoLang :(

    Repro:

    $script:testScript = "PSPathTest"
    $script:testDir = Join-Path $env:TMP "$testScript"
    $script:testFile = Join-Path $testDir "$testScript.bat"
    
    if (-Not (Test-Path $testDir))
    {
        Write-Host "-- Creating $testFile to test with."
        mkdir $testDir >$null
    }
    "echo Hello" | Out-File $testFile ascii
    
    try
    {
        # try invoking it directly
        Write-Host "-- Verifying that script runs: Expect to see 'Hello'"
        Invoke-Expression $testFile
        function CheckFor-Script
        {
            param([string] $path)
            $oldPath = $env:PATH
            $env:PATH = $path
            $result = Get-Command "$testScript" -ErrorAction SilentlyContinue
            $env:PATH = $oldPath
            return $result
        }
    
        Write-Host "-- Confirming script isn't available without path"
        if (CheckFor-Script "C:\Windows")
        {
            throw "Found '$testScript' in C:\Windows, can't proceed."
        }
    
        Write-Host "-- Confirming script *is* available with expanded path"
        if (-Not (CheckFor-Script "C:\Windows;$testDir"))
        {
            throw "Didn't find script with expanded path."
        }
    
        Write-Host "-- Confirming script is NOT available with unexpanded or quoted paths"
        if (CheckFor-Script "C:\Windows;%TMP%\$testScript;`"$testDir`"")
        {
            throw "Using unexpanded/quoted path worked (unexpectedly)"
        }
    
        Write-Host "** Did not find $testScript (as expected :("
    }
    finally
    {
        Write-Host "-- Cleaning up"
        rmdir -Force -Recurse -ErrorAction SilentlyContinue $testDir
    }

    Monday, June 11, 2018 8:08 PM
  • 1. There is no longer any DOS. Despite the "C: prompt," the cmd.exe program is a Windows console-mode executable that, despite a superficial appearance, has nothing whatsoever to do with DOS. (DOS is an obsolete 16-bit real-mode operating system.)

    2. PowerShell does not use %varname% syntax for environment variable expansion; the syntax is instead $env:Varname.

    3. We recommend starting your debugging by writing a short script that contains only the absolute minimum amount of code needed to reproduce the problem. You then need to explain what isn't working and how it isn't working. (We can't see your screen.)


    -- Bill Stewart [Bill_Stewart]

    Monday, June 11, 2018 8:12 PM
    Moderator
  • Extra quotes never needed in PowerShell.  Please reread the question and answer carefully and try to understand the actual issue.

    The topic is very old and has  been marked as answered.


    \_(ツ)_/

    Monday, June 11, 2018 8:13 PM
  • same thing happened with me when i using windows power shell on windows 10 so please help me how to solve this problem
    Sunday, August 11, 2019 12:59 PM
  • While I don't have a permanent solution, turns out that the "refreshenv" command does indeed run even when "cmd" itself does not run.

    See my example run:

    C:\Users\juan_m_medina> cmd
    cmd : The term 'cmd' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify
    that the path is correct and try again.
    At line:1 char:1
    + cmd
    + ~~~
        + CategoryInfo          : ObjectNotFound: (cmd:String) [], CommandNotFoundException
        + FullyQualifiedErrorId : CommandNotFoundException
    
    C:\Users\juan_m_medina> $env:Path.split(";")
    C:\Program Files\ConEmu\ConEmu\Scripts
    C:\Program Files\ConEmu
    C:\Program Files\ConEmu\ConEmu
    C:\Users\juan_m_medina\AppData\Local\Microsoft\WindowsApps
    C:\Users\juan_m_medina\AppData\Local\Yarn\bin
    C:\Users\juan_m_medina\AppData\Local\Programs\Fiddler
    C:\Program Files\kdiff3
    C:\Users\juan_m_medina\AppData\Roaming\npm
    %SystemRoot%\system32
    %SystemRoot%
    %SystemRoot%\System32\Wbem
    %SYSTEMROOT%\System32\WindowsPowerShell\v1.0\
    %SYSTEMROOT%\System32\OpenSSH\
    C:\Program Files\1E\NomadBranch\
    C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\DAL
    C:\Program Files\Intel\Intel(R) Management Engine Components\DAL
    C:\ProgramData\chocolatey\bin
    C:\Program Files (x86)\vim\vim80
    C:\Program Files\Microsoft VS Code\bin
    C:\Program Files (x86)\Yarn\bin\
    C:\Program Files\Git\cmd
    C:\Program Files\OpenSSH-Win64
    C:\Program Files\Microsoft SQL Server\130\Tools\Binn\
    C:\Program Files\Microsoft SQL Server\Client SDK\ODBC\170\Tools\Binn\
    C:\Program Files\nodejs\
    C:\Program Files\dotnet\
    C:\Users\juan_m_medina> refreshenv
    Refreshing environment variables from the registry for powershell.exe. Please wait...
    Finished
    C:\Users\juan_m_medina> cmd
    Microsoft Windows [Version 10.0.17134.950]
    (c) 2018 Microsoft Corporation. All rights reserved.
    
    C:\Users\juan_m_medina>
    

    Thus my temporary solution while I figure out what happened to this computer (brand new Windows 10 install) is to add "refreshenv" to my Microsoft.PowerShell_profile.ps1 script so it gets executed immediately.

    Do note I did try all other solutions/suggestions on this thread to no avail. Path is filled in (as seen on my example) and includes the proper folders. Similar setup works in other computers without the need for refreshing the environment. I will also check and comment if I find out that "cmd" is being hijacked by something else. Hope this helps someone, I may post later on if I manage to address this in a less clunky way.

    Thursday, September 19, 2019 3:31 PM
  • 1) "refreshenv" is not a native Windows command.

    2) This problem might be because your Path is set as data type REG_SZ instead of REG_EXPAND_SZ.

    3) Your issue is break/fix and not a scripting question.


    -- Bill Stewart [Bill_Stewart]

    Thursday, September 19, 2019 8:23 PM
    Moderator