'clip.exe' is not recognized as an internal or external command

[greenmooseSE]

Problem
For whatever reason I nowadays get below error message when running Set-ClipboardText from Powershell Core:

VERBOSE: Windows: using clip.exe
'clip.exe' is not recognized as an internal or external command,
operable program or batch file.
Set-ClipboardText : Invoking the platform-specific clipboard utility failed unexpectedly.

Running clip.exe works fine but not when called via cmd.exe:

C:\>clip.exe /?

CLIP

Description:
    Redirects output of command line tools to the Windows clipboard.
    This text output can then be pasted into other programs.

Parameter List:
    /?                  Displays this help message.

Examples:
    DIR | CLIP          Places a copy of the current directory
                        listing into the Windows clipboard.

    CLIP < README.TXT   Places a copy of the text from readme.txt
                        on to the Windows clipboard.
C:\>cmd.exe /c clip.exe /?
'clip.exe' is not recognized as an internal or external command,
operable program or batch file.

Solution
Works fine when using Get-Command to resolve full path

[string]$clipExePath = (Get-Command clip.exe).Path;
cmd.exe /c $clipExePath '<' $tmpFile

[mklement0]

That's all very mysterious; clip.exe should be in C:\Windows\system32\clip.exe, and C:\Windows\system32 should always be in $env:PATH.

What does (Get-Command clip.exe).Source report?

Are there malformed entries in $env:PATH?

What does nowadays mean? Did you upgrade to a new PS Core version, and what is that version?

[iricigor]

I cannot reproduce on my pwsh with latest Windows 10. Ad PATH check, @greenmooseSE can you also compare cmd path with PSCore path? It should be the same, but you never know. What the command "$(cmd.exe /c PATH)" -eq "PATH=$($env:PATH)" gives you in PS Core?

However, I did this test and it shows unexpected behaviour.

I copied clip.exe from system32 to my current location, i.e. c:\temp. Then inside of that folder, I executed cmd.exe /c clip.exe /? and I got nothing for the output.

Regardless of the root cause of a problem, @mklement0 can solution be to use full path instead of clip.exe here?

[greenmooseSE]

Investigated a bit more and my issue seems to be when invoking cmd.exe from a pwsh.exe shell the %PATH% variable get corrupted (for whatever reason it seems to be too long) so my standard items that should be part of PATH are not working either.

When I am invoking cmd.exe via Start->Run, or from a "standard powershell" shell, it works as expected and the length of %PATH% value is a lot smaller.

Difference in size when doing echo %PATH% >file.txt:

(So far I have not had any issues with this other than when using ClipboardText, I have modified it locally though with above change to get it working for me)

[mklement0]

Thanks, guys.

Even though the problem turned out to be external to this module, I've decided to follow @iricigor's suggestions and use full paths for the execution of the external shells and clipboard programs (where known) in the just-published https://www.powershellgallery.com/packages/ClipboardText/0.1.8

Using full paths for executables in known locations is preferable from a security and predictability standpoint.

However, @iricigor, I'm mystified by your clip.exe-in-c:\temp example - did you find the cause?