Environment variables value pass to powershell script in prep command

[javenli]

Since my monitors setup is a bit complex, e.g. 2 external monitors(through a KVM switch, so these monitors might connect to another PC sometimes) + 1 pikvm + 1 emulated monitor, I need a program solution to handle all scenario. My goal is to always set the virtual monitor as primary monitor and change the resolution, refresh rate and HDR setting automatically, and revert back when stream ends.

Here I choose Powershell because:

1. It comes with Windows natively.
2. There are couple Powershell command to check monitor status.

So I decided to write a Powershell script and made Sunshine to call the script. The prep command like:
powershell -ExecutionPolicy Bypass -File E:\Apps\Sunshine\MonitorStreaming.ps1 -action start -width "%SUNSHINE_CLIENT_WIDTH%" -height "%SUNSHINE_CLIENT_HEIGHT%" -fps "%SUNSHINE_CLIENT_FPS%"

It's clear that the script will accept 4 parameters: action, width, height, fps. You can easily tell the usage by their names.

However, there is an issue when I tried to print these values in Powershell script, e.g:
Write-Host "[$start_time]Script called with action=$action, width=$width, height=$height, fps=$fps"

What I got is something like:
[2024-08-21 16:26:58]Script called with action=start, width=%SUNSHINE_CLIENT_WIDTH%, height=%SUNSHINE_CLIENT_HEIGHT%, fps=%SUNSHINE_CLIENT_FPS%

That means these environment variables are not correctly expand with their actual value. I also tried below prep command but no luck:
powershell -ExecutionPolicy Bypass -File E:\Apps\Sunshine\MonitorStreaming.ps1 -action start -width %SUNSHINE_CLIENT_WIDTH% -height %SUNSHINE_CLIENT_HEIGHT% -fps %SUNSHINE_CLIENT_FPS%
powershell -ExecutionPolicy Bypass -File E:\Apps\Sunshine\MonitorStreaming.ps1 -action start -width $env:SUNSHINE_CLIENT_WIDTH% -height $env:SUNSHINE_CLIENT_HEIGHT -fps $env:SUNSHINE_CLIENT_FPS

Anybody know how to fix?

[ReenigneArcher]

Well you're using cmd's method instead of powershell's.

You can just access the env variables inside your script. They don't need to be arguments... Or you can Google how to pass env variables to powershell?

[javenli]

Yes. That's why the script is working. Because even the env variables are not expanded with their actual values, when calling the command inside the script, it will work.

So I can say there is a workaround for this issue.
However, if we try to reproduce the issue with Windows Terminal(using 'cmd' not powershell terminal) to understanding the root cause.

E:\Apps\Sunshine>set SUNSHINE_CLIENT_WIDTH=1920
E:\Apps\Sunshine>set SUNSHINE_CLIENT_HEIGHT=1080
E:\Apps\Sunshine>set SUNSHINE_CLIENT_FPS=60
E:\Apps\Sunshine>powershell -ExecutionPolicy Bypass -File test.ps1 -action start -width "%SUNSHINE_CLIENT_WIDTH%" -height "%SUNSHINE_CLIENT_HEIGHT%" -fps "%SUNSHINE_CLIENT_FPS%"
Script called with action=start, width=1920, height=1080, fps=60

The test script does nothing but just print the value of input parameters and we can see the values are correctly passed into the script.

So I suspect the issue is in the command invocation in Sunshine.

BTW, which terminal is Sunshine using? cmd or powershell?

[ReenigneArcher]

You aren't using cmd in Sunshine though. Sunshine doesn't run commands in any terminal. You can use cmd syntax if you prefix your command with cmd /c though.

[javenli]

Yes, by adding cmd /c, the env vars actual values are passed correctly.

Now it's like this:
cmd /c powershell -ExecutionPolicy Bypass -File E:\Apps\Sunshine\MonitorStreaming.ps1 -action start -width "%SUNSHINE_CLIENT_WIDTH%" -height "%SUNSHINE_CLIENT_HEIGHT%" -fps "%SUNSHINE_CLIENT_FPS%"

Now what I got from logging:
[2024-08-22 10:59:33]Script called with action=start, width=3840, height=2160, fps=60

Means that values are passed correctly.

[ReenigneArcher]

Like I said originally though, you don't need to pass them as arguments. Just set the variables in your ps script to the value of the env variables like you normally would in PowerShell.

[javenli]

Yes, sure it will work as well.

It's just personal preference as a programing practice to keep scripts less coupled with running environment.

But of course, it almost means nothing in this context, as it's not a software project.