Never write a batch wrapper again

This is a super clever way to workaround the fact that you can't just double click .ps1 files. Bravo. It's not terribly useful for me personally, but I can see where it might be for others.

It seems like some of the negativity you're getting might also be because it's working around intentional design decisions in PowerShell. Like, MS very explicitly didn't want PowerShell stuff to be one-click runnable to prevent phishing/malware style attacks that try to trick users into running stuff on their machine. Obviously, there are plenty of ways around it like this. But it's still one more hurdle attackers have to deal with.

I think my biggest peeve with using something like this regularly would be confusing my code editor's syntax highlighting and auto-completion. Obviously not an insurmountable problem, but possibly enough to make me keep separate copies of the core script and the wrapper.

Doesn't '%~f0' just resolve to C:\path\wrapper.cmd?

Nifty, thanks for the explanation.

For anyone else wondering about the expansion variable (%~fs0) you can read more by issuing this command in cmd

for /?

In addition, substitution of FOR variable references has been enhanced.
You can now use the following optional syntax:
%~I         - expands %I removing any surrounding quotes (")
%~fI        - expands %I to a fully qualified path name
%~dI        - expands %I to a drive letter only
%~pI        - expands %I to a path only
%~nI        - expands %I to a file name only
%~xI        - expands %I to a file extension only
%~sI        - expanded path contains short names only
%~aI        - expands %I to file attributes of file
%~tI        - expands %I to date/time of file
%~zI        - expands %I to size of file
%~$PATH:I   - searches the directories listed in the PATH
               environment variable and expands %I to the
               fully qualified name of the first one found.
               If the environment variable name is not
               defined or the file is not found by the
               search, then this modifier expands to the
               empty string

It's like a shebang line for PowerShell in batch... mind blown.

From the looks of it, you could start with PowerShell starting from the second line, I love compact yet powerful things like that.

Thank you! I asked this question on the IRC and basically got shamed off the channel. "Why would you use command prompt?!" "YUK!" "Just open Powershell and run your script. Done."

Its tiring to constantly have to explain life to people like this.

This is great, my goto has always been to basically do this where a windows shortcut opens cmd which opens powershell which calls a script but this removes a layer. Definitely can see using this in the future, thank you!

If you want it to be an .exe - why not just make it an .exe? There are applications out there that can make a PowerShell script an executable without having to use batch or cmd such as:

https://gallery.technet.microsoft.com/scriptcenter/PS2EXE-GUI-Convert-e7cb69d5

This is neat! Definitely going to use this. I have a mess of scripts for different builds that can really benefit from this

I run into the need to run scripts on systems I don't control that are limited to PowerShell 2.0. Here's a change to get this working with PowerShell 2.0 by removing the need for GC -Raw option.

# 2>NUL & @CLS & @PUSHD "%~dp0" & @"%SystemRoot%\System32\WindowsPowerShell\v1.0\powershell.exe" -v 2 -nol -nop -ep 4 "gc '%~f0'|Out-String|iex" & @POPD & @EXIT /B
# Working with PowerShell version 2.0
# script contents
write-host 'Hello'
write-host 'World!'

This is incredibly useful for me right now. I have a management agent that lets me embed scripts, but it can’t use .PS1 because I have no control over the ExecutionPolicy parameter, and I can’t have a separate .CMD because I don’t control the paths used by the agent and can’t rely on a secondary distribution mechanism for a second file.

What I had done so far was ran a shitty/broken .PS1 minifier, escaped that one liner for the command prompt, and piped that into powershell.exe -Command -. It worked but it. was. ugly.

Your tip just made this so much easier (in effort and on my psyche). Thanks!

That's really interesting thank you.

I probably won't use it though, since it'll probably make maintance harder for anyone looking for my scripts in the future.

At work, what I did was create a shortcut .lnk file that calls PowerShell.exe and feeds in the absolute path of the folder in the same directory. Then I just set that .lnk file to Run as Admin.

Hey OP, you might enjoy reading this:

Heredoc for Windows Batch

Just for fun and to see if it could be done, I used this technique to create a single batch file that embedded a Dockerfile. The batch file builds a Windows executable from a single Python source file. Inside the container, the RUN command downloads Python and PyInstaller. It then compiles the Python code to a .exe.

It was kinda cool to get it all working in a single file.

Your solution is great. I have icons on Users' desktops that invoke a batch file that simply calls a ps1. I am going to investigate using your idea instead of using the wrapper .bat file.

Clever. And very nice writeup, with your comments!

FYI, there's some good stuff buried in cjcox4's downvoted-to-oblivion comment - worth expanding, thanks OP!

I remember doing something like this. Here’s a JScript version: https://www.reddit.com/r/PowerShell/comments/8qsndn/sneaky_powershell_trick_run_completely_without_a/e0lwxe5/

Looks like only the first @ is needed. It’s per-line and not per-command. Everything after it is not echoed.

I've gotten in the habit of writing simple AHK (autohotkey) scripts and converting it to an exe using the native converter. Most virus scanners do not flag AHK (thankfully) and then you can put in an icon, put in elevation, and do some pre-run stuff using AHK's language (such as searching multiple locations for the source script).

Example AHK to launch a ps1 file in a the same folder:

RunWait *RunAs "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -file "%A_WorkingDir%\install.ps1" -executionpolicy bypass

Or another one, that will search every drive for a script:

DriveGet, list, list
Loop, Parse, list
{
    path = %A_LoopField%:\cb\blah.ps1
    if(FileExist(path)) {
        RunWait *RunAs "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -file "%path%" -executionpolicy bypass
        break
    }
}

[deleted]

As for this...

Why would you want to wrap your PowerShell in batch? Users! This allows people to double-click

... so does turning your file into an .exe, this is why PS2Exe exists. No need to a batch file wrapper.

https://gallery.technet.microsoft.com/scriptcenter/PS2EXE-GUI-Convert-e7cb69d5

https://www.powershellgallery.com/packages/ps2exe/1.0.1

BTW, you can double click a .ps1 to run it, just change the file association from the default of text to powershell.exe.

But, don't, there is a reason MS set the default for .ps1 to be a text file. To prevent users from doing exactly what you set up here.

Quite frankly, I've always been of the opinion, that .bat/.vbs/,hta/.cmd should always have been associated as text. If one needs to run such things, they should know-how. Just as they have to learn how to use MSOffice. This is why you can just double-click a .vba/.bas file has have it run either, it has to be run from within MSOffice files normally, though one could automate that call as well.

This double click stuff is how hackers have been able to easily whack environments for decades, so, why enable PowerShell, which is far more powerful to fall into this space.

Bold of you to assume my users can double click a batch file without constant coaching

I use this to get the current path in powershell, alas it is broken if using wrapper.cmd

$scriptDir = split-path -parent $MyInvocation.MyCommand.Definition # get relative path

This does the trick

$scriptDir = (Get-Item -Path ".\").FullName # get relative path

Is it possible to use this while passing command line parameters?

eg.

wrapper.cmd hello "arg 2"

Or is it still going to need a separate calling bat/cmd file?

Tried adding %* after iex but end up with:

iex : The input object cannot be bound to any parameters for the command either because the command does not take pipeline input or the input and its properties do not match any of the parameters that take pipeline input.
At line:1 char:50
+ [IO.File]::ReadAllText('Z:\wrapper.cmd')|iex hello arg 2
+                                                  ~~~~~~~~~
    + CategoryInfo          : InvalidArgument: (# 2>NUL & u/CLS ...ep -seconds 5
:String) [Invoke-Expression], ParameterBindingException
    + FullyQualifiedErrorId : InputObjectNotBound,Microsoft.PowerShell.Commands.InvokeExpressionCommand

1. Users should right click and Run As Powershell

2. You should create a simple Shortcut powershell.exe -command "& 'C:\users\DevinSysAdmin\Script.ps1' -Arguments"

Hmmm why not just make a module, and as part of a logon script it import it on machines? That way it don’t matter what machine you’re on if you have access to run the module cmdlets you just can...

If it’s to hard to be using command line for some people, maybe they need to learn or just not use things that are too hard for them. Yes I sound like an ass but it’s true

I just use shortcut files.

So effectively you have turned your wrapper into an incredibly hard to parse multi-stage command line.

What is the benefit of this?

@ is the splatting operator in Powershell, and @{} is a "splat" of an empty dictionary giving no result. At the same time, commands prefixed by @ won't be echoed by cmd.exe. Thus, the prefix @{}# 2>NUL& can be used to start a comment in PowerShell while still yielding no output by cmd.exe

But, does it prevent multiple postings to reddit? No.