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.
- Create a Python virtual environment (after
cd
ing to your project directory):powershellpython -m venv venv
- Activate the environment:powershellLook!
.\venv\Scripts\activate
(venv)
appears before the command prompt, success!powershell(venv) PS C:\my_project>
- Deactivate the environment:powershell
(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!