From CMD to PowerShell: Solving the "ps1" Script Execution Issue (Scripts Activate.ps1)

For many Python developers on Windows, CMD (Command Prompt) is like a faithful old friend: simple and reliable. But as we pursue efficiency and richer functionality, PowerShell is becoming increasingly popular.

However, when you eagerly type a familiar command in PowerShell, you might encounter a jarring red error message, as if the new world is saying "No":

PS C:\my_project> .\venv\Scripts\activate
.\venv\Scripts\activate : Cannot load file activate.ps1 ... because running scripts is disabled on this system.
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : SecurityError: (:) []，PSSecurityException
    + FullyQualifiedErrorId : UnauthorizedAccess

Why does this happen? Read on.

CMD's Comfort Zone: Why It "Never Fails"

Let's first reminisce about the good old days with CMD. Activating a virtual environment typically looked like this:

C:\my_project> venv\Scripts\activate
(venv) C:\my_project>

Why so simple? Because you're actually running a batch file named activate.bat. CMD's design philosophy is to execute batch commands, and its security model is very lenient, allowing you to run these .bat files by default. It's simple, reliable, but also relatively basic in functionality.

Why Switch to PowerShell?

If CMD is so hassle-free, why bother switching? Because PowerShell offers significant improvements in efficiency:

• Intelligent Tab Completion: Much more powerful than CMD's completion, suggesting commands, parameters, paths, etc.
• Linux-like Command Aliases: You can directly use familiar commands like ls, clear, cp, mv, etc., for seamless environment switching.
• Powerful Pipelines and Object Manipulation: You can pass the output of one command (as a structured object) to another for complex processing, something CMD can't match.
• Excellent Terminal Experience: In Windows Terminal, PowerShell can achieve multi-pane, multi-tab, rich color schemes, and custom configurations, combining aesthetics and functionality.

The conclusion: It's absolutely worth it! The initial configuration hassle will pay off in long-term development efficiency.

PowerShell's "Test": Understanding Execution Policy

When you switch from CMD to PowerShell, the command to activate a virtual environment also changes. You're no longer running a .bat file, but a script specifically prepared for PowerShell: activate.ps1.

This is the heart of the problem.

PowerShell treats all .ps1 files as scripts and introduces an important security mechanism called Execution Policy. It acts like a "security guard", and by default, its policy is Restricted, meaning no scripts are allowed to run, to prevent you from accidentally executing malicious code.

So, when you run .\venv\Scripts\activate, you're actually requesting the "guard" to let the activate.ps1 script pass. The guard checks: "Nope, my rule is to forbid all scripts," and rejects you, giving you that red error message.

A One-Time Solution: Giving Your PowerShell the "Green Light"

The solution to the initial problem lies here, and the key is to adjust the policy to RemoteSigned.

To solve this, we just need to adjust the "guard's" rules, telling him: "Scripts I write myself locally are safe, please allow them to run." We recommend using the RemoteSigned policy, which strikes a perfect balance between security and convenience.

The RemoteSigned policy means:

• Allow running all scripts you create locally (like activate.ps1).
• Scripts downloaded from the internet must have a digital signature to run.

Steps (Once and For All)

Modifying the system-level execution policy requires administrator privileges.

1. Open PowerShell as an Administrator

• Search for powershell in the Start menu.
• Right-click "Windows PowerShell" and select "Run as administrator".

2. Execute the Modification Command In the administrator window that appears, enter the following command and press Enter:

Set-ExecutionPolicy RemoteSigned

3. Confirm the Change The system will ask you to confirm the change. Type Y and press Enter.

Execution Policy Change
...
[Y] Yes(Y)  [A] Yes to All(A)  [N] No(N)  [L] No to All(L)  [S] Suspend(S)  [?] Help (default is "N"): Y

If there are no errors, you've succeeded! You can now close this administrator window.

Alternative (If No Administrator Privileges)

If you don't have administrator privileges, you can modify the policy for the current user only. In a normal PowerShell window, execute:

Set-ExecutionPolicy -Scope CurrentUser RemoteSigned

Again, enter Y to confirm.

Embrace the New Workflow: Smooth Operation in PowerShell

Now, your PowerShell is ready to go. Let's experience the new, efficient Python virtual environment workflow.

1. Create a Python virtual environment (after cding to your project directory):

   python -m venv venv

2. Activate the environment:

   .\venv\Scripts\activate

   Look! (venv) appears before the command prompt, success!

   (venv) PS C:\my_project>

3. Deactivate the environment:

   (venv) PS C:\my_project> deactivate

Quick Reference: CMD vs. PowerShell Similarities and Differences

The transition from CMD to PowerShell might encounter a small hurdle due to the execution policy, but it's more like a "rite of passage". Once you complete this one-time configuration, you'll open the door to a more efficient and enjoyable development experience.

Operation	CMD (Old Friend)	PowerShell (New Partner)
Activation Command	venv\Scripts\activate	.\venv\Scripts\activate
Running Files	activate.bat (batch)	activate.ps1 (script)
Initial Obstacle	Almost never	Common, due to execution policy
Solution	Not needed	Run Set-ExecutionPolicy RemoteSigned as administrator

Welcome to the world of PowerShell, and enjoy the power and convenience it brings!