I usually use the shortcut described here: How do I start PowerShell from Windows Explorer? to open a PS session in a specific folder. Just using powershell to open the sessions
However is no longer working, every time I write powershell on the address bar and hit enter it take me to the folder: C:\Users\MyUser\Documents\PowerShell (I'm in a Windows 10 laptop)
It seems to be related only to this shortcut as I have tried a few other things and they work. List of things I have tried/checked already below:
powershell -noprofile it work opening a PS session as expected
No, my $Profile file does not have anything to set the location of the PS Session.
powershell.exe works as expected
powershell_ise works as expected
going to File --> Open Windows Powershell works as expected
Checked my environment variables and nothing strange there either
It seems to be related to the fact that I installed PS core 6 recently. This installation introduced the folder C:\Users\MyUser\Documents\PowerShell (it's a new folder vs the ones that existed with Windows Powershell) and that's why the windows explorer now opens a folder instead of the command line.
I suppose I will need to get used to powershell.exe instead of powershell from now on.
Related
I'm having an issue regarding the Powershell extension in VSCode. I am getting a blank line, and a different command for the script being executed.
I get this on vscode:
PS>
PS>. "C:\JulyCode\HelloWorld.ps1"
Hello World
PS>
On the ISE I currently get this:
PS> C:\JulyCode\HelloWorld.ps1
Hello World
PS>
I'd prefer to have the latter. Not sure if this is a workspace setting or what to troubleshoot. VSCode didn't do this before, and I imagine I made a change or the extension made a change. I've tried new workspaces, new settings (using my older but saved settings), etc and still had no luck. Also it seems to only run on the Extension: Powershell Integrated Console. Not sure if that can be changed either.
I have "terminal.integrated.shell.windows": "C:\\Program Files (x86)\\PowerShell\\6\\pwsh.exe" set in my settings.json file, and when I open VS code without any files open the terminal is set to pwsh, but when I open a PowerShell script, there is suddenly a second terminal (PowerShell Integrated Console) and running the debugger results in PowerShell 5.1 being used instead of 6 (Core).
What do I need to do to get PowerShell version 6 used whenever I open a .ps1 document? Running it from the command line works, but is a pain.
The PowerShell Integrated Console is what the PowerShell extension uses to process .ps1 files and is controlled by a different setting (powershell.powerShellExePath).
You can change this setting easily by opening a .ps1 file, then clicking on the "5.1", "6.0", etc. icon in the bottom right of the status bar. This will open the PowerShell Session Menu where you can select which version of PowerShell you want the extension to use (out of the versions you have installed).
Your choice will then be persisted in your user settings under powershell.powerShellExePath.
I have a PowerShell script like this:
$tfExe = path/to/tf.exe
& $tfExt ... do something
On my computer (and other PCs) if I run this script I get the .exe output in my PowerShell window.
When I run the script on another computer (with Windows 7 32-bit) it opens a cmd window, the output displayed there, and the window is immediately closed.
The issue occurs for each .exe tool, even in robocopy.
Why does this happen and how can I change it?
I had another issue with my PowerShell and the solution to that issue also solved this issue.
In my PATHEXT environment variable I didn't have .exe. When I added it, the issue solved and all the .exe tools ran smoothly and the output appears in the PowerShell window.
I had a similar issue and figured out I had deleted the folder I was executing the commands from.
PATHEXT was ok:
But this was not (I had deleted it outside of PowerShell - oops):
Navigating to another path solved the issue.
You are starting an external exe, so it's working as intended. You could however try using cmd.exe /K - more info here https://ss64.com/nt/cmd.html
I’m using the Powershell extension for Visual Studio Code. I updated the profile:
C:\Users\xxxxxxxx\Documents\WindowsPowerShell\Microsoft.VSCode_profile.ps1
To include some functions and variables that I want to make available to other scripts. When I reference a variable from the profile within another script, it does not appear that the profile has been loaded. I suspect this because the variable value is blank when I query it from the VS Code console. If I run the same test from the standard Powershell console with an associated profile, the variable value is resolved.
Can anyone tell me what, if anything, I need to do to use a Powershell profile in VS Code while debugging?
There are several profiles. The starting point is the four locations that you can find by reading the following properties of PowerShell's built-in $profile variable.
$profile.CurrentUserAllHosts
$profile.CurrentUserCurrentHost
$profile.AllUsersCurrentHost
$profile.AllUsersAllHosts
As noted in this article by The Scripting Guy, because Windows has both Powershell and the Powershell ISE, you have at least two possible values of Current Host, so at least 6 profiles.
I've tested this in the Visual Studio Code terminal window, and it seems that the "CurrentHost" profiles are the same as you get by simply running a powershell instance. I'd assume then that Code isn't seen as a distinct host, and just runs a normal powershell.
Once you've got that far, there's another possible complication, which is that the AllUsers profiles are down in C:\Windows\System32 and hence on a 64 bit system, also mirrored in C:\Windows\SysWOW64\. So depending on whether you are using a 32 or 64 bit editor, and whether the Powershell is hosted in a 32 or 64 bit process, it is quite possible that the file you are editing has no influence on the Powershell.
Inside your debug session run: $profile. This will return the path to currently used profile file, so you can make your changes there.
Alternatively you could change the system wide profile in C:\Windows\System32\WindowsPowerShell\v1.0\profile.ps1
With the just released version 0.10.0 of the VS Code PowerShell extension debugging with a previously loaded profile.ps1 being available is now implemented. Note that the interactive console and the debugger share the same PS session.
If you type $profile in the "PowerShell Integrated Console" of VSCode, you will see the path to the profile used:
C:\Users\xxx\Documents\WindowsPowerShell\Microsoft.VSCode_profile.ps1
Now if you type $profile in a normal terminal, you will see your "normal" profile: C:\Users\xxx\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1
Now the easiest solution that did the trick for me is to create a hard link between the two files (the VSCode_profile.ps1 file didn't exist in my case):
mklink /H Microsoft.VSCode_profile.ps1 Microsoft.PowerShell_profile.ps1
Reload VSCode and you are all set!
Having failed to get PowerGUI to work properly I've fallen back on PowerShell ISE. However if I run this as Administrator it won't let me set any breakpoints.
If I launch as normal (my login is a member of Administrators) all is well but because I need to script some tasks that require full administrator rights this is no good.
I have saved the script as a proper file (i.e. it's not "untitled1.ps1") but no joy.
I'm running Windows 7 x64 Ultimate.
Strangely this doesn't seem to be a problem on my Windows 2008 R2 dev box (I'm logging in as user that is a member of Administrators then running PS ISE "As Administrator" and breakpoints are set and hit.
Any ideas why this would be?
I also faced the same issue, saving the file to a physical location enabled all debugging capabilities.
It looks like there's a problem with PowerShell and square brackets in folder and filenames.
Both PowerGUI and PowerShell ISE won't hit breakpoint if the script being debugged resides in a folder with [ or ] in the name.
I notice you're running x64. Is there any chance that you're running x64 ISE but have only set the execution policy away from restricted on x86 (or vice-versa).
I am using Visual Studio Code and in my case, I was missing the powershell extension.
Was facing the same issue because I had used other editor to make changes to the ps1 file. After opening the file with PowerShell ISE and clicking "Save" solved the issue for me.