In this post I found the way to detect the installed Powershell version: Determine installed PowerShell version.
When I type "powershell" into "Execute as" (Win+R) the powershell opens with the title:
C:\Windows\System32\WindowsPoershell\v1.0\powershell.exe
However, the commands from the linked SO question deliver following output:
So my question: Why is there v1.0 in the title of the shell window whereas the other commands tell me that I have version 2?
Your PowerShell version is 2. The title shows the path to the PowerShell executeable. I think the reason why all new PowerShell version are located there (in v1.0) is because so many cmd scripts invoking some PowerShell code using this file path (e. g. Scheduled Tasks). But I may be wrong.
Another reason could be, that its not possible to run two different PowerShell Versions side-by-side.
Related
What is the difference between [pwsh] and [Powershell Integreted Console] on VS Code?
I usualy use pwsh.
Today, when I installed the powershell extension and then tried to update the powershell, the Powershell Integreted Console started up and found out. What is this?ćć
pwsh[.exe] is the executable file name of PowerShell [Core] (v6+), the cross-platform edition of PowerShell built on .NET Core / .NET 5+; by contrast, powershell.exe is the executable name of the legacy Windows PowerShell edition (v5.1-), built on the Windows-only .NET Framework (v4.8-)
Windows PowerShell comes with Windows itself, whereas PowerShell [Core] must be installed on demand (on all supported platforms).[+]
VSCode (Visual Studio Code) has an integrated terminal (console) that can run any shell, such as cmd.exe, bash, or pwsh or powershell.
Shells that run in the integrated terminal by default have no special integration with the files being edited. They show by their executable file name in the dropdown list in the integrated terminal's toolbar; e.g.:
By contrast, the PowerShell Integrated Console is a special shell that comes with the PowerShell extension and offers integration with PowerShell code being edited, notably to provide linting and debugging support, among other features.
The PowerShell Integrated Console starts on demand when you first open/activate an editor with PowerShell code in a session, and it shows as follows in the integrated terminal's toolbar:
You can use the PowerShell extension's configuration to choose the specific PowerShell executable to use, which on Windows allows you to choose between running PowerShell [Core] (pwsh.exe) and Windows PowerShell (powershell.exe) in the PowerShell Integrated Console.
If a PowerShell [Core] version is installed and it is installed in a well-known location[*], it will be used by default; the fallback on
Windows is Windows PowerShell. Since PowerShell [Core] versions can be installed side by side, you can switch between different versions, if installed.
If a PowerShell [Core] version in installed in a nonstandard location and is therefore not discovered automatically, you can tell the PowerShell extension where to find it, either via the Settings GUI or via settings.json, as shown in the linked topic and the bottom section of this answer.
Whenever the active tab is a PowerShell source-code file, the status bar in the bottom-right corner shows the PowerShell version that is being used if you however over or click on the {} icon; versions >= 6 imply PowerShell [Core].
If configured, there's a separate icon that directly invokes the PowerShell session menu when clicked and which reflects the active version number - again, see the bottom section of this answer; e.g.:
[+] as of v7.0; time will tell if PowerShell [Core] will ship with future versions of Windows, and perhaps even other platforms.
[*] From the linked docs: "This feature looks at a few well-known paths on different operating systems to discover install locations of PowerShell. If you installed PowerShell to a non-typical location, it might not show up initially in the Session Menu. You can extend the session menu by adding your own custom paths." If you use one of the official installers, the PowerShell extension should find your installation.
I have a windows batch script that, depending on the user menu selection, opens a powershell.exe and passing a variable to run a .ps1 script. I then use Bat To Exe Converted (v3.0.10) to convert it to an exe. A few hours ago I made changes to the PS script and copied it to the Win'2019 server and it accepted it. Now, I just changed two letters in a write-host message command and it keeps quarantining the file. Since this will be passed to customers I can't be telling them to ignore it or white list it.
I'm guessing the .bat and .ps1 files are throwing Windows Defender off. Funny how it was fine just a few hrs ago. Even if I undo the 2 letters I added it still deleting the exe.
The .bat is quite big and it'd be very difficult for me to convert and add inside the .ps1 script in hope of not setting off the trojan. What other options do I have to fix this? Is there a process or url to notify MS about this to get them to fix this false positive?
NOTE: No other Windows version or 3rd party antivirus that I've tried is detecting the exe infected. Only Win'2019's Defender is.
It looks like MS has fixed the false-positive with my code. I came in to work this morning and tried to copy the exe again and this time it worked. I didn't even contact MS (we don't have a support contract anyway).
Btw the exe consisted of a bat and ps1 script that just downloads some public install files (such as 7zip) from an https address, saves them and when running the exe the user would just get a menu of which of the downloaded programs they want to install.
The issue can be reproduced creating a simple new console application (Language : C++) with Visual Studio 2019 (Community Edition) and then just run program: Ctrl + F5. The solution that worked for me, to run the program, was to add the folder as an exclusion in Windows Defender Antivirus. I couldn't find any solution on other threads
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.
I am a complete Noob on Windows and, for the first time of my life, I have to make a Powershell script to install various services on a server. From what I understood, silent installations are made this way:
Start-Process "C:\Path\To\some_installer.exe" -ArgumentList "/some /argument" -Wait -PassThru
But I cant figure a way to identify what the arguments should be for this given .exe. On Linux, I would launch the installer and answer to the prompts one by one to know what the arguments are supposed to be. Then:
(echo arg1; echo arg2) | my command
But since Start-Process does not display a similar behavior (or I am not using it properly), I am lost. I tried the -RedirectStandardOutput but getting nothing in the output file. How do you identify the argument list to provide?
Just like Linux, Windows has many package installation tools. The difference is that the Windows installers are mostly designed for GUI. So there is no standard for CLI. For each installation, you need to check for the installer.
If it's an MSI file, you can use the Microsoft docs. If it's an executable, you need to check for the installer. Many software use common installation wizards, but many of them use custom ones.
If you want to use it like Linux, you can use scoop or chocolatey. You can have a local repository in your network then share. Or just use internet. Then you can have silent installation by default.
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!