1

After adjusting the PATHEXT and PATH environment variables, PowerShell scripts can accessed from the Command Prompt. The issue comes, however, is that when attempting to execute a script (ie, CMD> foobar where foobar.ps1 is on the path) Notepad opens the script instead of Powershell being invoked to execute the script.

The goal is to be able to run CMD> foobar and invoke the PowerShell script and return the results directly into the console.

Here are a few solutions to the problem that somewhat come close to, but don't, meet the needs:

  • Setting the Execution Policy to a more permissive setting
    • While this helps, it doesn't let me run the .ps1s directly from the CMD command line.
  • Opening the PowerShell prompt and running the script
    • This kind of defeats the purpose. While I am shifting to a PowerShell-first mindset, I need solutions in the interim.
  • Setting registry keys to double click the script
    • This helps somewhat, but I don't think it actually does anything for this problem.
  • Prefixing the command with powershell -File
    • This doesn't solve the problem because I want to CMD> foobar, not CMD> powershell -File foobar.
TheBrenny
  • 141

2 Answers2

2

Turns out that the solution resides with File Associations - but not in the Registry (although it probably does exist in the registry somewhere).

I stumbled across this post (which is a script to set bulk file associations), after I stumbled across this page which tries to solve the problem.

Unfortunately, the latter says you only need to assoc .ps1=pwsh.exe, which is only 50% complete. Turns out you need to ftype and assoc because they work in conjunction and execute things correctly:

CMD> ftype Custom.PowerShellScript="C:\Program Files\PowerShell\7\pwsh.exe" "%0" %*
CMD> assoc .ps1=Custom.PowerShellScript

After running these two commands, you might be prompted to run using a particular executable, and it'll look wrong to start with, but running the command again (yes, the idiot check) proves that this is actually the solution!

Edit: The ftype command was slightly wrong. Although it did work, this revision enables it to be executed with command line arguments.

TheBrenny
  • 141
0

This is a Windows OS, risk management setting.

You have to call powershell.exe or pwsh.exe (if PSCore is installed and you prefer to use that version.).

PowerShell is default associated with notepad for a reason. Specifically security.

Do, not change this association. .ps are not executables, hence why you need to launch powershell/pwsh.exe explicitly. Changing that association also would allow just opening Windows Explorer, and double-clicking to run, but again, unnecessary exposure risk.

Changing that extension will open you up to unneeded risk cases and may be against your corporate security/risk policy if this is a corporate device, and thus expose you potentially to a negative HR event.

Windows sets the default action for *.PS1 files to open them in Notepad, instead of sending them to the PowerShell command interpreter. This is to directly prevent the accidental execution of malicious scripts when they’re simply double-clicked.

If this is your personal device, then sure, you do you, and of course accept all consequencies thereafter

To configure double-clicking to launch PowerShell scripts directly:

Set-ItemProperty HKCR:\Microsoft.PowerShellScript.1\Shell '(Default)' 0

To configure double-clicking to open PowerShell scripts in the PowerShell ISE:

Set-ItemProperty HKCR:\Microsoft.PowerShellScript.1\Shell '(Default)' 'Edit'

To restore the default value (sets double-click to open PowerShell scripts in Notepad):

Set-ItemProperty HKCR:\Microsoft.PowerShellScript.1\Shell '(Default)' 'Open'

Or just right-click on a .ps1 file in Windows Explorer, and change the 'Open with' option to powershell.exe or pwsh.exe and you are off to the races. Change it back when you want it to go back to notepad.

postanote
  • 4,846
  • So given that this is to mitigate security issues, how is running the command with PowerShell.exe -ExecutionPolicy Bypass -File .foobar.ps1 meant to be any better? How is this not an issue with .bat scripts - I can run them directly from the command prompt? – TheBrenny Dec 23 '22 at 04:19
  • MS has never said, 'ExecutionPolicy' is a security boundary. It's another hurdle that a user must traverse to execute PS scripts. guidance/docs: about_Execution_Policies 'about_Execution_Policies PowerShell's execution policy is a safety feature that controls the conditions under which PowerShell loads configuration files and runs scripts. This feature helps prevent the execution of malicious scripts.' – postanote Dec 23 '22 at 04:28
  • 1
    Unlike bat/cmd/vbs/WMI (cscript.exe/vbscrpti.exe/wmic.exe), It forces a user to explicitly take the extra steps to do this, vs simple runs or double click. There were/are many nefarious activities that occurred and still occur with all those prior to PS which were never addressed. There are details which say, some of that legacy stuff are targets for remediation and or removal. Yet, until official MS docs come, that is heresay. – postanote Dec 23 '22 at 04:31
  • 1
    There are many ways to bypass virtually any security thingy, for ease of use reasons. Just because you can does not mean you should. One can drive without insurance and a driver's license, well until they get caught. Again, if your org Risk Team is monitoring, and has a policy against this, could/will cost you your job. I see this regulalry. – postanote Dec 23 '22 at 04:40
  • I feel like this is important enough to note, even though it doesn't solve the question. Thanks for your answer and comments. It's certainly important to understand what risks I'm subjecting myself to, and these comments certainly mean I have to weigh up those risk factors. – TheBrenny Dec 23 '22 at 05:08
  • @TheBrenny, no worries. I do risk management as part of my role, and I've had to punt several folks working to bypass corporate rules. Changing the association, to avoid typing powershell, means your point here PowerShell.exe -ExecutionPolicy Bypass -File .foobar.ps1 is not valid. That switch is only valid when you call powershell/pwsh.exe. So, changing the association, without manually setting the EP, means the file would not run anyway if that EP is set to say restricted by your org. So, to do what you say, that EP must also be set properly in advance. – postanote Dec 23 '22 at 05:23
  • @TheBrenny, one other Item I meant to add fo you regarding PS Sec: *From Microsoft* PowerShell’s Security Guiding Principles – postanote Dec 23 '22 at 07:53