Skip to main content
SysAdmin Shell Scripting Essentials

Execute PowerShell Script from PowerShell: Call Operator

Learn how to execute PowerShell scripts from PowerShell or cmd.exe using call operator (&), dot-sourcing, and powershell.exe -File. Includes execution policy bypass, exit codes, and troubleshooting for Windows PowerShell 5.1 and PowerShell 7.x.

Execute PowerShell script from PowerShell is the procedure of running a .ps1 file from a PowerShell session or from cmd.exe using the call operator (&), dot-sourcing (.), or the -File parameter. Requires appropriate execution policy.

# From within PowerShell — call operator (recommended)
& "C:PathScript.ps1" [-Param1 Value1] [-Param2]

Tested on Windows 11 22H2 with PowerShell 7.6 and Windows PowerShell 5.1.

Syntax

# From within PowerShell — call operator (recommended)
& "C:PathScript.ps1" [-Param1 Value1] [-Param2]

# From within PowerShell — dot-sourcing (runs in current scope)
. "C:PathScript.ps1"

# From cmd.exe or Run dialog
powershell.exe -ExecutionPolicy Bypass -File "C:PathScript.ps1" [-Param1 Value1]

# From cmd.exe — with -NoExit to keep console open
powershell.exe -NoExit -File "C:PathScript.ps1"

# From PowerShell — using the call operator with inline arguments
& "C:PathScript.ps1" -Server HQ -Port 8080

Options and Flags

Flag / Syntax Type Default Description
-ExecutionPolicy Bypass String Restricted (Windows) Temporarily bypasses script execution restriction for this session. Does not modify system policy.
-File <Path> String N/A Specifies the .ps1 script to execute. All subsequent arguments are passed to the script as literal strings.
-NoExit Switch False Keeps the PowerShell console open after script completes. Useful for debugging or inspecting output.
& (call operator) Operator N/A Executes a command or script in a child scope. Required when path contains spaces or variables.
. (dot-source) Operator N/A Executes a script in the current scope. Variables and functions defined persist after completion.
-Command String N/A Executes a command string. Use & "C:PathScript.ps1" inside the string. Prefer -File for scripts.
-WindowStyle Hidden String Normal Launches PowerShell with a hidden window. Used in scheduled tasks and silent automation.
See also  nohup Command in Linux: Syntax, Flags & Troubleshooting

Usage Examples

Example 1: Run a script from the current directory

# Navigate to the script location and execute
cd "C:Deploy"
.DeployApp.ps1 -Environment Production -Version 3.2.1

If the path contains no spaces, .DeployApp.ps1 executes the script in a child scope. The -Environment and -Version parameters are passed as named arguments. All script-scope variables are discarded after completion.

Example 2: Invoke a script from cmd.exe with bypass policy

powershell.exe -ExecutionPolicy Bypass -File "C:ScriptsHealthCheck.ps1" -Server "DB-01"

This is the standard pattern for running PowerShell scripts from batch files, scheduled tasks, or CI/CD agents. The -ExecutionPolicy Bypass flag overrides the default Restricted policy for that single invocation — no permanent change is made to the registry or GP.

Example 3: Dot-source a utility script to load functions

# Load all functions from a shared lib into the current session
. "C:LibCommonFunctions.ps1"

# Now call functions defined in the script
Get-ServerStatus -Name "WEB-01"
Invoke-LogCleanup -RetentionDays 30

Dot-sourcing runs the script in the caller’s scope. Any functions, aliases, or variables defined in CommonFunctions.ps1 persist in the session. Use this pattern for shared libraries — but avoid it for deployment scripts where scope isolation is desirable.

Example 4: Run with explicit exit code capture

# From PowerShell
& "C:ScriptsBackup.ps1"
$exitCode = $LASTEXITCODE
Write-Host "Script exited with code $exitCode"

# From cmd.exe
powershell.exe -File "C:ScriptsBackup.ps1"
echo %ERRORLEVEL%

PowerShell maps the script’s exit statement to $LASTEXITCODE. The cmd ERRORLEVEL variable captures the same value. Always capture exit codes in automation to detect failures.

Troubleshooting & Common Errors

Error Message / Code Root Cause Resolution Command
File cannot be loaded because running scripts is disabled on this system Execution policy is Restricted (Windows default). powershell.exe -ExecutionPolicy Bypass -File "script.ps1"
'.' is not recognized as an internal or external command Ran .script.ps1 from cmd.exe, not from PowerShell. Use powershell.exe -File "script.ps1" instead of .script.ps1.
The term 'script.ps1' is not recognized Script not found in PATH or current directory; spaces in path without &. & "C:My Scriptsscript.ps1"
Exit code 255 PowerShell.exe could not parse or locate the script. Verify absolute path. Use -File not -Command for scripts.

powershell.exe -File "C:existsscript.ps1"
Access to the path is denied File system permissions; script not readable. Check ACLs: icacls "C:Pathscript.ps1". Ensure the executing user has Read permission.
See also  lpr print Command Syntax, CLI Reference, Troubleshooting

Closing Tip

Always run PowerShell scripts from automation with -ExecutionPolicy Bypass -File and capture $LASTEXITCODE immediately, because no other single pattern consistently handles spaces, permissions, and exit-code propagation across both Windows PowerShell 5.1 and PowerShell 7.x.

Multi-Cloud Comparison

PowerShell script execution is a local OS operation. No cloud provider exposes a native subcommand to run a .ps1 file. The following table maps equivalent concepts for remote execution on cloud VMs.

Feature Local PowerShell AWS (EC2 / Systems Manager) Azure (VM / Run Command)
Run .ps1 on VM .script.ps1 aws ssm send-command --document-name "AWS-RunPowerShellScript" --parameters commands=["powershell -File script.ps1"] az vm run-command invoke --command-id RunPowerShellScript --scripts "powershell -File script.ps1"
Execution policy override -ExecutionPolicy Bypass Configure per-instance via Group Policy or ssm agent Configure per-instance via Azure Policy or custom script extension
Persist script output Redirect > output.log --output-s3-bucket-name (SSM) Output returned in command response; can write to blob storage
Pass arguments .script.ps1 -Arg1 Value1 --parameters "args"=["Value1"] --parameters "arg1=Value1"

Frequently Asked Questions

What is the difference between dot-sourcing (.) and the call operator (&) when executing a PowerShell script?

Answer: Dot-sourcing (.) runs the script in the current scope, while the call operator (&) runs it in a child scope.

Use . .script.ps1 when you want to persist script-defined functions or variables into the current session. Use & .script.ps1 to prevent scope pollution. The call operator also allows invoking a script by path stored in a variable: & $scriptPath.

When should I use the -ExecutionPolicy flag when executing a script?

Answer: Use -ExecutionPolicy Bypass when running a script from a non-trusted source or in automation to immediately override restrictive policies.

See also  PowerShell Command Windows Update - Verified Syntax and Flags

Example:

powershell.exe -ExecutionPolicy Bypass -File C:deployscript.ps1

This flag is valid for both powershell.exe and pwsh.exe. For scripts launched from within another PowerShell session, set the policy for the child process: Start-Process powershell.exe -ArgumentList '-ExecutionPolicy RemoteSigned -File .script.ps1'.

How do I fix ‘File cannot be loaded because running scripts is disabled on this system’ (error code: System.UnauthorizedAccessException)?

Answer: Set the execution policy to RemoteSigned or Bypass: Set-ExecutionPolicy -Scope CurrentUser RemoteSigned.

Run from an elevated PowerShell window:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope LocalMachine -Force

For a one-shot bypass without changing policy, launch the script with powershell.exe -ExecutionPolicy Bypass -File script.ps1. If Group Policy enforces the restriction, use Bypass at invocation or run powershell.exe -ExecutionPolicy Unrestricted for the session.

Does executing PowerShell scripts work on Linux and macOS with PowerShell Core?

Answer: Yes, PowerShell Core (pwsh) runs scripts cross‑platform.

On Linux/macOS, ensure the script has execute permissions (chmod +x script.ps1) and includes a shebang: #!/usr/bin/env pwsh. Execution policy is less restrictive on non‑Windows systems; however, Set-ExecutionPolicy is only supported on Windows. Use pwsh -File script.ps1 directly. For CI/CD pipelines, always specify the full path to the script.

What is the fastest way to execute a PowerShell script from PowerShell with minimal overhead?

Answer: Use the call operator with a direct path: & 'C:pathtoscript.ps1'.

For in‑process execution (no child process), call the script directly by its path. To bypass execution policy without spawning a new process, set policy once per session or use Set-ExecutionPolicy Bypass -Scope Process -Force. Avoid piping to Invoke-Expression (IEX) for performance. For parallel execution of many scripts, use $jobs = 1..10 | ForEach-Object { Start-Job -ScriptBlock { & "C:scriptsjob$_.ps1" } }.