-
Notifications
You must be signed in to change notification settings - Fork 25k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bat scripts to work with JAVA_HOME with parantheses #39712
Bat scripts to work with JAVA_HOME with parantheses #39712
Conversation
Pinging @elastic/es-core-infra |
the elasticsearch.bat and elasticsearch-env.bat won't work if JAVA contains parentheses. This seems to be the limitation of FOR /F IN (command) DO syntax. The JAVA variable present in a command contains a path to a binary to start elasticsearch (with spaces & parans). We can workaround the problem of spaces and parentheses in this path by referring this variable with a CALL command. Note that executing binaries with CALL is an undocumented behaviour (but works)
14cd39f
to
fe6435b
Compare
@rjernst would you be able to have a look into this PR? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry this review never got published before. Some of these comments might have already been addressed.
.filter(path -> path.contains("Java") == false) | ||
.collect(joining(";")); | ||
|
||
sh.runIgnoreExitCode("cmd /c mklink /D 'C:\\Program Files (x86)\\java' $Env:JAVA_HOME"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you add a note that this can be done in powershell once we have min PS 5.0?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you mean the symbolic link creation? Is the PS 5 available since certain windows version?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we ingnore the exit code? If this fails, the test cannot proceed right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good spot, test should not proceed if this fails
@@ -193,6 +192,39 @@ public void test50StartAndStop() throws IOException { | |||
Archives.stopElasticsearch(installation); | |||
} | |||
|
|||
public void test51JavaHomeContainParansAndSpace() throws IOException { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Typo: Parans -> Parens
You might just rename this to "special characters" instead of only allow parens and spaces, something like:
test51JavaHomeWithSpecialCharacters
final String javaHome = sh.run("$Env:JAVA_HOME").stdout.trim(); | ||
|
||
try { | ||
final String newPath = Arrays.stream(originalPath.split(";")) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should not be necessary anymore. In 6.7 there shouldn't be any test using PATH anymore, except intentionally.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
so the vagrant images are guaranteed not to have java inside PATH? I feel like it wouldn't harm to make sure PATH does not have java in there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, java is in the PATH. I don't think we should change that. In 6.7 I made sure all the tests pass in JAVA_HOME, to avoid triggering the deprecation warning output starting in that version when using java on the PATH. In 7.0+ we no longer look at PATH at all to find java.
Archives.runElasticsearch(installation, sh); | ||
|
||
Archives.stopElasticsearch(installation); | ||
} catch (IOException e) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No need to catch, just add a checked exception to the test method
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it is because this code is inside lambda onWindows( ()-> {here} )
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should change the signature of PlatformAction.run
to have a checked Exception
, so that we don't need these intermediate try/catches.
public void test51JavaHomeContainParansAndSpace() throws IOException { | ||
assumeThat(installation, is(notNullValue())); | ||
|
||
Platforms.onWindows(() -> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe we have a similar test in bats, can you add the linux side here as well so we can just remove that test?
@@ -58,5 +58,5 @@ set ES_DISTRIBUTION_FLAVOR=${es.distribution.flavor} | |||
set ES_DISTRIBUTION_TYPE=${es.distribution.type} | |||
|
|||
if not defined ES_TMPDIR ( | |||
for /f "tokens=* usebackq" %%a in (`"%JAVA% -cp "!ES_CLASSPATH!" "org.elasticsearch.tools.launchers.TempDirectory""`) do set ES_TMPDIR=%%a | |||
for /f "tokens=* usebackq" %%a in (`CALL %JAVA% -cp "!ES_CLASSPATH!" "org.elasticsearch.tools.launchers.TempDirectory"`) do set ES_TMPDIR=%%a |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Discussed this offline: at first glance I had thought this was modifying the deprecated for loop that searches the path for java. Now I see this is a different loop (although I am confused why we need a loop at all: TempDirectory only prints one line). I believe this entire PR can be moved back to basing on master.
@elasticmachine run elasticsearch-ci/packaging-sample |
This needs to be backported to 6.7 branch (for 6.7.2 version) and 7.x (for 7.1) |
…39712) the elasticsearch.bat and elasticsearch-env.bat won't work if JAVA contains parentheses. This seems to be the limitation of FOR /F IN (command) DO syntax. The JAVA variable present in a command contains a path to a binary to start elasticsearch (with spaces & parens). We can workaround the problem of spaces and parentheses in this path by referring this variable with a CALL command. Note that executing binaries with CALL is an undocumented behaviour (but works) closes elastic#38578 closes elastic#38624 closes elastic#33405 closes elastic#30606
the elasticsearch.bat and elasticsearch-env.bat won't work if JAVA contains parentheses. This seems to be the limitation of FOR /F IN (command) DO syntax. The JAVA variable present in a command contains a path to a binary to start elasticsearch (with spaces & parens). We can workaround the problem of spaces and parentheses in this path by referring this variable with a CALL command. Note that executing binaries with CALL is an undocumented behaviour (but works) closes elastic#38578 closes elastic#38624 closes elastic#33405 closes elastic#30606
the elasticsearch.bat and elasticsearch-env.bat won't work if JAVA contains parentheses. This seems to be the limitation of FOR /F IN (command) DO syntax. The JAVA variable present in a command contains a path to a binary to start elasticsearch (with spaces & parens). We can workaround the problem of spaces and parentheses in this path by referring this variable with a CALL command. Note that executing binaries with CALL is an undocumented behaviour (but works) closes elastic#38578 closes elastic#38624 closes elastic#33405 closes elastic#30606
…40768) the elasticsearch.bat and elasticsearch-env.bat won't work if JAVA contains parentheses. This seems to be the limitation of FOR /F IN (command) DO syntax. The JAVA variable present in a command contains a path to a binary to start elasticsearch (with spaces & parens). We can workaround the problem of spaces and parentheses in this path by referring this variable with a CALL command. Note that executing binaries with CALL is an undocumented behaviour (but works) closes #38578 closes #38624 closes #33405 closes #30606 backports: * Bat scripts to work with JAVA_HOME with parentheses(#39712) * Link to SYSTEM_JAVA_HOME on windows (#40806)
the elasticsearch.bat and elasticsearch-env.bat won't work if JAVA contains parentheses. This seems to be the limitation of FOR /F IN (command) DO syntax. The JAVA variable present in a command contains a path to a binary to start elasticsearch (with spaces & parens). We can workaround the problem of spaces and parentheses in this path by referring this variable with a CALL command. Note that executing binaries with CALL is an undocumented behaviour (but works) closes elastic#38578 closes elastic#38624 closes elastic#33405 closes elastic#30606
@pgomulka I'm assuming there is nothing left to backport and removed the backport pending label. |
the elasticsearch.bat and elasticsearch-env.bat won't work if JAVA contains parentheses. This seems to be the limitation of FOR /F IN (command) DO syntax.
The JAVA variable present in a command contains a path to a binary to start elasticsearch (with spaces & parans). We can workaround the problem of spaces and parentheses in this path by referring this variable with a CALL command.
Note that executing binaries with CALL is an undocumented behaviour (but works)
closes #38578
closes #38624
closes #33405
closes #30606