While debugging a script in VS code's Powershell Integrated Console if I test for a registry path it's printing False even though the path exists.
If I execute the same instruction in PowerShell window or VS Code's Powershell Console it prints True.
I am running all instances with Admin privileges.
Check if Get-PSProvider shows Registry providers in both Integrated Console and Powershell Console. If it does not exist for some reason, test path simply won't understand Registry:: root. Environments may be different as explained here: https://powershell.org/2013/10/19/the-shell-vs-the-host/
You're using the wrong syntax argument (I'd suggest testing in the DBG console or the powershell.exe process as an FYI)... Also, don't post code as images, it's a bad practice that will not get your question answered.
The PowerShell way:
Test-Path -Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\GMS Software'
The issue was with VS code installation. A complete uninstall of VS code and reinstalling it resolved the problem.
Related
So I've just downloaded Visual Studio Code to use as my default IDE for learning Python. I'm running on a 64-bit machine so I made the default terminal windows powershell.
The place where I'll be saving most of my files is about 8 folders deep which all show up in the terminal before any commands can be written. Is there any way to hide or shorten the file path in the terminal?
As #Biclops suggested, there is good info here: configure PowerShell to only show the current folder in the prompt
However, I needed more basic info to get this to work. This is a very good resource to get started: Windows PowerShell Profiles. So I first followed the steps suggested there:
[always using vscode's integrated terminal using PowerShell]
test-path $profile (is there a profile set up?)
new-item -path $profile -itemtype file -force (assuming the answer to the above is false)
notepad $profile (opens notepad)
paste in (from the SuperUser answer above)
function prompt {
$p = Split-Path -leaf -path (Get-Location)
"$p> "
}
save (you shouldn't have to chose a location, it is already done for you)
reload vscode - you will probably get an error message about running scripts (or just do next step before reload)
Set-ExecutionPolicy RemoteSigned -Scope CurrentUser (at your integrated terminal PS prompt, also from the SuperUser answer)
reload vscode
You should be good to go!
Great Question and Great Answers.
But this information is dated, and Windows is currently updating from Windows 10 to Windows 11. In addition, the base Windows PowerShell has been incorporated into the new Windows Terminal Preview app. which is being used here.
The solution provided above by Mark and Tarruda23 (above) almost works. But Windows throws an error - described below.
The steps:
First, it was necessary to determine whether a profile existed. Using the Windows Explorer, the following path was checked. If a profile already exists, this path shows where an existing profile should be found. On this PC, no profile ( .ps1 ) file existed and this folder was empty. Don't close the Explorer.
C:\Users\prior\OneDrive\Documents\WindowsPowerShell
Since no file exists, a new file needed to be created. This new file must be saved with a specific name - shown below.
Navigate to the empty folder and open PowerShell. The .ps1 profile must be created and saved in this folder. Use the Powershell's build-in text editor to create the new file. Type:
ISE
Then type or paste the following into the empty text file:
function prompt {
$p = Split-Path -leaf -path (Get-Location)
"$p> "
}
Save this file with the following name:
Microsoft.PowerShell_profile.ps1
Use the PowerShell to open Notepad and check that .ps1 file. This demonstrates the Windows system has found the new .ps1. Next close the Notepad.
Notepad $profile
Now the PowerShell is probably displaying an error message in red text. This error message reads in part:
\Microsoft.PowerShell _profile.ps1 cannot be loaded because running scripts is disabled on this system.
Run the PowerShell as the Administrator. Type the following.
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned
Windows will prompt with a question:
Do you want to change the execution policy?
Type y for yes. This will change and remove the Windows default settings that prevents running script files. Once done, this will remove that error message.
All should be good now. PowerShell will now start and run with shorter and abbreviated PS> prompt that shows either the User name, or the name of the folder where the PowerShell is running.
I am trying to run a VBScript using some code I already have written for generically running executables. I have used it successfully with EXE & BAT files, but VBS files are giving me headaches.
I found this that does it with CMD and Invoke-Expression, and this that does it with &. But I have found no references to doing it with Start-Process, and when I try something simple like
Start-Process wscript.exe -ArgumentList:"UNC PATH TO HelperTest.vbs"
I get
Execution of the Windows Script Host failed. (Not enough storage is
available to complete ths operation. )
But I can run the super simple VBS file directly no problem. This only happens when the VBS is on a network share. Running it locally works fine. Also, not including a fully qualified path works fine, as in
Start-Process wscript.exe -ArgumentList:"HelperTest.vbs"
So it's not an actual permissions issue on the share. Am I just bumping in to some obscure bug and I am not going to get this to work, or am I doing something wrong and getting confused by a not very helpful error message?
I'm trying to have powershell create a folder for me and it works fine when I type it into the console. However, when I run the same command as a script, no folder is created and no error messages are supplied.
This is the line of code I am using.
new-item - path c:\test\ -name testfolder -itemtype directory
edit: I am on Windows 7
This should be a comment, but I cannot comment. There is definitely nothing wrong with that line of code. It runs on my machine, either from the terminal window or as a script. Because the code works for you at the terminal window but not when executing as a script my first guess is that your system may be configured to disallow powershell scripts. This is the default setting, and it will prevent a script file from executing but will not prevent commands typed at the prompt from working. Open a powershell session and type get-executionpolicy. If it returns "restricted" then you have found the culprit. This setting can be changed by opening an elevated powershell session (run as admin) and typing set-executionpolicy -executionpolicy RemoteSigned. Of course you should read about what those settings mean before changing them to determine what is best for your situation. For example the remotesigned option means that scripts originating from your machine will execute without a trusted signature, but external scripts will require a signature.
I'm the author of several Chocolatey packages that need to set environment variables as part of the proper "installation" of the package. For example: ANT_HOME, MW_HOME, and JAVA_HOME in the Java ecosystem should point to the installation directory for ant, weblogic, and java, respectively.
And, since Chocolatey is a machine-wide package manager, my thought would be to set these machine-wide (MSDN).
[System.Environment]::SetEnvironmentVariable("JAVA_HOME", "path/to/jre/install", "Machine")
If I just run that, I get the expected permission exception
Exception calling "SetEnvironmentVariable" with "3" argument(s): "Requested registry access is not allowed."
If I run the same command in an elevated prompt, manually, everything works fine. So, I need to invoke it in an elevated prompt. With Chocolatey, you're supposed to use: [Start-ChocolateyProcessAsAdmin][2] like so
Start-ChocolateyProcessAsAdmin #"
[System.Environment]::SetEnvironmentVariable("JAVA_HOME", "path/to/jre/install", "Machine")
"#
It prompts for elevation (I always run in a normal prompt when developing to be sure that it's actually working), but I see red errors flash by and this message with no warning/error
Elevating Permissions and running C:\windows\System32\WindowsPowerShell\v1.0\powershell.exe -NoProfile -ExecutionPolicy unrestricted -Command "& import-module -name 'C:\Chocolatey\chocolateyinstall\helpers\chocolateyInstaller.psm1'; try{[System.Environment]::SetEnvironmentVariable("JAVA_HOME", "path/to/jre/install", "Machine"); start-sleep 6;}catch{write-error 'That was not sucessful';start-sleep
8;throw;}". This may take awhile, depending on the statements.
What gives?
UPDATE:
Some combination of the following makes it work, mysteriously... adding line-terminators (even to single statements) and wrapping all the arguments in single quotes.
Start-ChocolateyProcessAsAdmin #"
[System.Environment]::SetEnvironmentVariable('JAVA_HOME', 'path/to/jre/install', 'Machine');
"#
I would still like a non-brute-force answer. I'm sure it's a combination of PowerShell's nightmare string quoting/interpreting rules + Chocolatey's invocation.
UPDATE:
I'm also having trouble with multiple statements, even though I'm separating them!
Start-ChocolateyProcessAsAdmin #"
[System.Environment]::SetEnvironmentVariable('MW_HOME', 'path/to/wl/install', 'Machine');
[System.Environment]::SetEnvironmentVariable('WL_HOME', 'path/to/wl/install/wlserver', 'Machine');
"#
I saw, but did not capture, a Chocolatey log statement on screen that showed one of the line-terminators removed!
THOUGHT:
I mean, should I just not do this and write an easy "User" environment variable instead? It's not correct! The damn things are installed machine-wide... I don't want to give up yet.
Why not use the built in helper for this, Install-ChocolateyEnvironmentVariable. The usage is quite simple...
Install-ChocolateyEnvironmentVariable 'JAVA_HOME' 'path\to\jre' 'Machine'
I'm using Hudson version 1.324 for CI and have a couple of issues:
Environment:
Windows Server 2008
Powershell v1.0
Hudson 1.324 running as a service
Hudson Powershell Plugin installed
Psake (aka. "Powershell Make/Rake" available from Github) 0.23
(All current/latest versions as of this initial post)
I have a Powershell (PS) script that works to compile, run NUnit tests, and if successful, create a 7z file of the output. The PS script works from the command line, on both my local development box as well as the CI server where Hudson is installed.
1) Execution Policy with Powershell.
I initially ran a PS console on the server, ran Set-ExecutionPolicy Unrestricted, which allows any script to be run. (Yes, I realize the security concerns here, I'm trying to get something to work and Unrestricted should remove the security issues so I can focus on other problems.)
[This worked, and allowed me to fire off the PS build script from Hudson yesterday. I then encountered another problem, but we'll discuss that more in item #2.]
Once Hudson could fire off a PS script, it complained with the following error:
"C:\Windows\system32\WindowsPowerShell\v1.0\powershell "&
'OzSystems.Tools\psake\psake.ps1' '.\oz-build.ps1'" The term
'OzSystems.Tools\psake\psake.ps1' is not recognized as a cmdlet, funct
ion, operable program, or script file. Verify the term and try again.
At line:1 char:2
+ & <<<< 'OzSystems.Tools\psake\psake.ps1' '.\oz-build.ps1'"
Using the same command line, I am able to successfully execute the PS script from the command line manually. However Hudson is unable to get PS to do the same. After looking at additional PS documentation I also tried this:
"& 'OzSystems.Tools\psake\psake.ps1' '.\oz-build.ps1'"
and got a similar error. There does not appear to be any documentation for the Powershell plugin for Hudson. I've gone through all the Powershell plugin files and don't see anything that's configurable. I can't find a log file for Hudson to get additional information.
Can anyone help me past this?
2) I spent yesterday wrestling with #1. I came in this AM and tried to dig in again, after restarting the Hudson server/service, and now it appears that the ExecutionPolicy has been reset to Restricted. I did what worked yesterday, opened a PS console and Set-ExecutionPolicy to Unrestricted. It shows Unrestricted in the PS console, but Hudson says that it doesn't have rights to execution PS scripts. I reopened a new PS console and confirmed that the ExecutionPolicy is still Unrestriced -- it is. But Hudson evidently is not aware of this change. Restarting Hudson service again does not change Hudson's view of the policy.
Does anyone know what's going on here?
Thanks, Derek
I just ran into the problem of running powershell scripts in hudson. The thing is that you are running a 32-bit process of Java, and you've configured Hudson for 64-bit but not for 32-bit. See the following thread we created at microsoft.
http://social.technet.microsoft.com/Forums/en/winserverpowershell/thread/a9c08f7e-c557-46eb-b8a6-a19ba457e26d
If your lazy.
1. Start powershell (x86) from the start menu as administrator
2. Set the execution policy to remotesigned
Run this once and your homefree.
When Running PowerShell from a scheduled task or Hudson you want to:
Specify the -ExecutionPolicy parameter (in your case: -Ex Unrestricted)
Specify that command using either -Command { ... } or -File NOT BOTH and not without specifying which you mean.
Try this (except that I don't recommend using relative paths):
PowerShell.exe -Ex Unrestricted -Command "C:\Path\To\OzSystems.Tools\psake\psake.ps1" ".\oz-build.ps1"
To be clear, this will work too:
PowerShell.exe -Ex Unrestricted -Command "&{&'OzSystems.Tools\psake\psake.ps1' '.\oz-build.ps1'}"
The first string after -Command is interpreted as THE NAME OF A COMMAND, and every parameter after that is just passed to that command as a parameter. The string is NOT a script, it's the name of a command (in this case, a script file)... you cannot put "&'OzSystems.Tools\psake\psake.ps1'" but you can put "OzSystems.Tools\psake\psake.ps1" even if it has spaces.
To quote from the help (run PowerShell -?) emphasis mine:
-Command
Executes the specified commands (and any parameters) as though they were
typed at the Windows PowerShell command prompt, and then exits, unless
NoExit is specified. The value of Command can be "-", a string. or a
script block.
If the value of Command is "-", the command text is read from standard
input.
If the value of Command is a script block, the script block must be enclosed
in braces ({}). You can specify a script block only when running PowerShell.exe
in Windows PowerShell. The results of the script block are returned
to the parent shell as deserialized XML objects, not live objects.
If the value of Command is a string, Command must be the last parameter
in the command , because any characters typed after the command are
interpreted as the command arguments.
I have been having the same problems as you (as you've seen from my comments). I have given up on the powershell launcher and moved to running things using the batch file launcher. Even though I had set the system to unrestricted that setting didn't seem to matter to hudson's launcher. I don't know if it runs in some other context or something, even adding things to the global profile.ps1 didn't seem to help. What I ended up doing was running
powershell " set-executionpolicy Unrestricted; & 'somefile.ps1'"
which does what I need, although it isn't ideal. I've e-mailed the plugin author about this and will update.
For question #1, try this (assuming you are using PowerShell 2.0):
"C:\Windows\system32\WindowsPowerShell\v1.0\powershell -executionPolicy Unrestricted -file OzSystems.Tools\psake\psake.ps1 C:\{path}\oz-build.ps1"
You are using "." for the path to oz-build.ps1. I suspect you will need to provide the full path to your oz-build.ps1 file to make this work. Unless the infrastructure that executes the command above happens to have the current dir set correctly. And even if it is set correctly for the "process", that only matters to .NET/Win32 API calls and not to PowerShell cmdlets. Current dir in PowerShell is tracked differently than the process's current dir because PowerShell can have multiple runspaces running simultaneously. That sort of global, mutable value doesn't work in this concurrent scenario.
As for question #2, what account does the Hudson service run under? Make sure that account has executed Set-ExecutionPolicy RemoteSigned (or unrestricted).
I just got through this exact problem. What a pain!
If you are running a 32-bit JVM on a 64-bit Windows, make sure that you set the execution policy for the 32-bit Powershell interface. I found my 32 bit executable here:
C:\Windows\syswow64\Windowspowershell\v1.0\powerhsell.exe
The 32- and 64-bit Powershell environments are completely distinct so setting the execution policy in one has no effect on the other.