Difference when executing Java command via CMD vs Powershell - caused by periods (".")

Jakg :

I've got an example Java application that requires an HTTP Proxy to be specified in some environments.

When I try running this using the argument as suggested on the Oracle website in CMD (Command Prompt) it works fine.

E:\>java -Dhttp.proxyHost=http://proxy.example.com -jar myJAR.jar
System properties...
[...]
http.proxyHost=http://proxy.example.com

You can see that the application has been run, and when listing the system properties it's correctly received the http.proxyHost property.

However, when I run this from Powershell, I get the following:

Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.

Try the new cross-platform PowerShell https://aka.ms/pscore6

PS E:\> java -Dhttp.proxyHost=http://proxy.example.com -jar myJAR.jar
Error: Could not find or load main class .proxyHost=http:..proxy.example.com

Here it appears some kind of breaking has occurred around the first "." and from then on it's treated the rest as another argument.

If the argument is quoted - e.g. -D"http.proxyHost"=http://proxy.example.com - then it works fine in Powershell.

Can anyone explain this behavior, please?

mklement0 :

Unfortunately, you're seeing a bug in PowerShell, still present as of v7.0:

Something that looks like a parameter to PowerShell is broken into two arguments at the . (period) - even though the argument should simply be passed through, given that an external program is called - see this GitHub issue; in your case, -Dhttp.proxyHost=http://proxy.example.com is unexpectedly passed as -Dhttp .proxyHost=http://proxy.example.com (note the space before the .)

There are two workarounds:

  • Quote the . character, using '.':

    java -Dhttp'.'proxyHost=http://proxy.example.com -jar myJAR.jar
    
  • Alternatively, as shown in Sergey Shu's answer, use --%, the stop-parsing symbol, to force PowerShell to pass all arguments through without applying PowerShell's usual parsing rules.

    • Caveat: Use of --% has major side effects, notably the inability to use variable references in the command and the inability to apply redirections - see this answer for details.

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=19049&siteId=1