"批量使用 PowerShell 命令的问题"

Question

I download a zip file from my cloud using a PowerShell command. The command works correctly in PowerShell AND in the command line. However, if I insert the command from the command line into my batch script, only the html is downloaded. Why does the command work correctly in the command line but not in the batch file? Im out of ideas :D

powershell Invoke-WebRequest """https://sync.luckycloud.de/d/fb56e4a8239a4c6cac7a/files/?p=%2FValheimServer%20Buddelkiste%20Modpack%20v3.4%20-%20Standart.zip&dl=1""" -OutFile """C:\Users\Anonymos\Downloads\servermodpack.zip"""

Answer 1

In a batch file - as opposed to the interactive cmd.exe command prompt ^[1] - you need to to escape % chars. as %% in order to pass them through literally :

powershell -c "Invoke-WebRequest 'https://sync.luckycloud.de/d/fb56e4a8239a4c6cac7a/files/?p=%%2FValheimServer%%20Buddelkiste%%20Modpack%%20v3.4%%20-%%20Standart.zip&dl=1' -OutFile C:\Users\Anonymos\Downloads\servermodpack.zip"

Note:

• I've used -c ( -Command ), the positionally implied Windows PowerShell CLI ( powershell.exe ) parameter explicitly for conceptual clarity (in PowerShell (Core) 7+ , whose CLI is pwsh , the default is now -f ( -File )).

• Also, enclosing the entire command line to pass to PowerShell in "..." is generally preferable to prevent cmd.exe metacharacters other than % from causing problems.

  • In case the command line requires use of embedded " characters, the safest way to escape them is to use "^"" (sic) with powershell.exe and "" with pwsh.exe - see this answer for details.

---

^{[1] In interactive use, % characters cannot technically be escaped , but they're retained as-is unless they're part of a cmd.exe -style environment-variable reference that refers to an existing environment variable, such as %OS% . However, there are ways to treat % literally even in such cases, as discussed in this answer . These techniques are important for invoking cmd.exe command lines programmatically from outside cmd.exe , such as from Node.Js or Python, because such programmatic invocations - perhaps surprisingly - use the rules of interactive cmd.exe sessions, not batch files.}