> It is easy to show that it doesn't:

Here:

    C:\Users\User\Documents> type .\test.ps1
    $Env:TESTENV = "Hello"
    C:\Users\User\Documents> echo $Env:TESTENV
    C:\Users\User\Documents> .\test.ps1
    C:\Users\User\Documents> echo $Env:TESTENV
    Hello

> What?

https://docs.microsoft.com/en-us/windows/win32/api/winbase/n...

Unlike sane architectures, on Windows, WinMain gets the entire command line as a single string, which means it's each process individually what breaks it into separate arguments.

> Here

Well... there is still no leak as there is no new shell spawn. I personally find this behavior way more natural then that of bash. If you don't want it, use variables. I can imagine coming from bash background that this irritates you.

> WinMain gets the entire command line as a single string

This has nothing to do with PowerShell which imposes its own parameter parsing standard so that no individual scripts do that. Also, when we are at it, I guess this "unsane" architecture is more flexible.

> Well... there is still no leak as there is no new shell spawn. I personally find this behavior way more natural then that of bash. If you don't want it, use variables. I can imagine coming from bash background that this irritates you.

It's a serious annoyance when you're doing build scripts that do stuff like setting $PATH. Suddenly, stuff breaks randomly depending on what you ran in that particular powershell window before. And there's a length limit too, so if you append to a variable you may find stuff breaks on the 5th invocation of the script.

It also has the annoying "feature" of leaving you in the last directory the script changed to. Most annoying for debugging stuff.

> This has nothing to do with PowerShell which imposes its own parameter parsing standard so that no individual scripts do that.

It's not specifically powershell related, but if you're running on Windows, the Windows design problems apply to everything, including powershell.

> Also, when we are at it, I guess this "unsane" architecture is more flexible.

And more failure prone. It may mean there's no way whatsoever to pass a given path to a program. If a program internally doesn't handle quoting and spaces right, you're screwed.

It can also mean security issues. No matter how well you write your code, a malicious party can give you a filename like "data.txt /deleteeverything ", and the program you're calling may choose to interpret that as an argument, regardless of any quoting you might do.

For that matter, if you want to have the same flexibility on Unix, you can just concatenate all of argv, and then do your own parsing.

> It's a serious annoyance when you're doing build scripts that do stuff like setting $PATH.

Indeed, I was bitten by this too. Honestly, its probably the best not to touch PATH and friends and resolve the problem some other way. Or you could use modules.

> It also has the annoying "feature" of leaving you in the last directory the script changed to.

Yeah, that might be problem. I used to use cd instead of cpush because of this. However, using good framework fixes this. Check out Invoke-Build for your build stuff and you will forget about all of that. Its totally epic.

> It may mean there's no way whatsoever to pass a given path to a program. If a program internally doesn't handle quoting and spaces right, you're screwed.

Regarding space, this is easily solvable by using short syntax. Regarding quoting, this seems like a less important case - its very rare to have quotes in the file names in my experience.