Closed hohwille closed 6 months ago
Some simple testing:
hohwille@CE49454 MSYS /d/projects/IDEasy/test/bin
$ export PATH=/d/projects/IDEasy/software/node:/d/projects/IDEasy/software/java/bin:/d/projects/IDEasy/software/mvn/bin:/d/projects/IDEasy/software/node:/d/projects/IDEasy/software/mvn/bin:/d/projects/IDEasy/software/java/bin:/c/Users/hohwille/bin:/c/Program Files/Git/usr/local/bin:/c/Program Files/Git/usr/bin:/c/Program Files/Git/usr/bin:/c/Program Files/Git/opt/bin:/c/Program Files/WindowsApps/Microsoft.WindowsTerminal_1.17.11461.0_x64__8wekyb3d8bbwe:/d/oracle-xe/product/18.0.0/dbhomeXE/bin:/c/WINDOWS/system32:/c/WINDOWS:/c/WINDOWS/System32/Wbem:/c/WINDOWS/System32/WindowsPowerShell/v1.0:/c/WINDOWS/System32/OpenSSH:/c/Program Files (x86)/GnuPG/bin:/c/Program Files/SlikSvn/bin:/c/Program Files/TortoiseSVN/bin:/c/Program Files/Git/cmd:/c/Program Files/Rancher Desktop/resources/resources/win32/bin:/c/Program Files/Rancher Desktop/resources/resources/linux/bin:/c/Users/hohwille/scripts:/c/Program Files/Git/usr/bin/vendor_perl:/c/Program Files/Git/usr/bin/core_perl
bash: syntax error near unexpected token `('
hohwille@CE49454 MSYS /d/projects/IDEasy/test/bin
$ export "PATH=/d/projects/IDEasy/software/node:/d/projects/IDEasy/software/java/bin:/d/projects/IDEasy/software/mvn/bin:/d/projects/IDEasy/software/node:/d/projects/IDEasy/software/mvn/bin:/d/projects/IDEasy/software/java/bin:/c/Users/hohwille/bin:/c/Program Files/Git/usr/local/bin:/c/Program Files/Git/usr/bin:/c/Program Files/Git/usr/bin:/c/Program Files/Git/opt/bin:/c/Program Files/WindowsApps/Microsoft.WindowsTerminal_1.17.11461.0_x64__8wekyb3d8bbwe:/d/oracle-xe/product/18.0.0/dbhomeXE/bin:/c/WINDOWS/system32:/c/WINDOWS:/c/WINDOWS/System32/Wbem:/c/WINDOWS/System32/WindowsPowerShell/v1.0:/c/WINDOWS/System32/OpenSSH:/c/Program Files (x86)/GnuPG/bin:/c/Program Files/SlikSvn/bin:/c/Program Files/TortoiseSVN/bin:/c/Program Files/Git/cmd:/c/Program Files/Rancher Desktop/resources/resources/win32/bin:/c/Program Files/Rancher Desktop/resources/resources/linux/bin:/c/Users/hohwille/scripts:/c/Program Files/Git/usr/bin/vendor_perl:/c/Program Files/Git/usr/bin/core_perl"
So this ugly Windows Folders with white-space and parenthesis (Program Files (x86)
) are some issue.
Be aware of that in your wrapper script.
Another question would be why are there path entries duplicated? I see this:
node
java
mvn
node
(duplicate)mvn
(duplicate)java
( duplicate)~/bin
git
(usr/local + usr + opt)Windows-Terminal
Oracle
(I had uninstalled this, uninstaller seems buggy)Windows
(system32 + plain + wbem + powershell + OpenSSH)GnuPG
SlikSvn
TortoiseSVN
Git
(again but no duplicate)Rancher
(win32 + linux)scripts
Git
(vendor_perl + core_perl)So these duplicates are IMHO a bug of the EnvironmentCommandlet
.
Does not have to be fixed as part of this story, but should also be addressed.
devonfw-ide environment variables have been set for /d/projects/IDEasy in workspace main
hohwille@CE49454 MINGW64 /d/projects/IDEasy/test/bin
$ echo $PATH
/d/projects/IDEasy/software/node:/d/projects/IDEasy/software/mvn/bin:/d/projects/IDEasy/software/java/bin:/c/Users/hohwille/bin:/mingw64/bin:/usr/local/bin:/usr/bin:/bin:/mingw64/bin:/usr/bin:/c/Users/hohwille/bin:/d/oracle-xe/product/18.0.0/dbhomeXE/bin:/c/WINDOWS/system32:/c/WINDOWS:/c/WINDOWS/System32/Wbem:/c/WINDOWS/System32/WindowsPowerShell/v1.0:/c/WINDOWS/System32/OpenSSH:/c/Program Files (x86)/GnuPG/bin:/c/Program Files/SlikSvn/bin:/c/Program Files/TortoiseSVN/bin:/cmd:/c/Program Files/Rancher Desktop/resources/resources/win32/bin:/c/Program Files/Rancher Desktop/resources/resources/linux/bin:/c/Users/hohwille/scripts:/usr/bin/vendor_perl:/usr/bin/core_perl
So no duplicates before invoking ideasy
so a bug of EnvironmentCommandlet
.
Already found the source of the bug: https://github.com/devonfw/IDEasy/blob/7fcddb5a505db40275a4a04801fc5dd88d6d357a/cli/src/main/java/com/devonfw/tools/ide/common/SystemPath.java#L109
IMHO we do not handle the different PATH syntax on windows between native Windows syntax (D:\projects\IDEasy\software
) and Bash-Syntax (/d/projects/IDEasy/software
). So before entering the loop we should check if we are on Windows and if so also compute the path transformation to bash syntax for softwarePath
and pass the result also to getTool
method:
https://github.com/devonfw/IDEasy/blob/7fcddb5a505db40275a4a04801fc5dd88d6d357a/cli/src/main/java/com/devonfw/tools/ide/common/SystemPath.java#L63
Maybe we should split this story into 3 aspects:
ide
wrapper script in bashide.bat
wrapper script in MS Dos.bashrc
and (if present) .zshrc
. This one might need to be connected with #101 and a potential uninstall functionality (no issue created for this yet).For the record: I am also thinking about renaming ideasy
binary to something more special. Regular end-users will always use the ide
wrapper script. When using code-completion in bash
and typing id[Tab]
the user will get ide
and ideasy[.exe]
as options what seems a little inconvenient. The other option would be to have our ideasy
binary not in the PATH
variable and therefore not in the bin
folder where the ide
script is located. But then the script needs some tweak to find ideasy
. However, the latter option might be better.
Auto-closed by PR #221 but not yet completed:
ide.bat
script.bashrc
so that the ide
wrapper script is defined as alias sourcing the script and to register the bash completion (like we did in devonfw-ide).Since this issue was magically reopend when I created #260 I can reuse it for another demand we need to implement:
$ ideasy env --bash
You are not inside an IDE installation: D:\projects
You are not inside an IDE installation: D:\projects
First line is on std out in white. Second line is on std err in red. The white output could be removed.
$ ideasy env --bash
export PATH="..."
MVN_VERSION="3.9.5"
INTELLIJ_VERSION="2023.3.2"
...
This is so far fully correct.
However, when we just call ide
as sourced script and you get the red error output if you are not inside a project but if you are in a project you get no output at all.
Like with devon
we should instead get something like this:
IDE environment variables have been set for /d/projects/IDEasy in workspace main
The message is already implemented here: https://github.com/devonfw/IDEasy/blob/be4ab474f32f343ff033c6de2e7acae90f0a0b1f/cli/src/main/java/com/devonfw/tools/ide/context/AbstractIdeContext.java#L252
Please note that you cannot output the message to std out from ideasy env --bash
. So either we need to print it as error or we have to think of a different approach (but building it from the wrapper script does not seem to be a good idea as we also need an ide.bat
script and we therefore want to have as little logic in these scripts as possible).
As a devonfw-ide user, I want to be able to use the new
ide
CLI seamlessly so that I can continue to work like I was used to with devonfw-ide. That is if I just callide
this will set my environments according to the IDEasy project I am currently located in.For this we have already implemented our Java IDE and build-process to create native image binaries. All this already supports an environment commandlet that prints out all the variables to set. However, a process (our ide.exe) cannot set/change the environments of the current shell (e.g. CMD, bash, or powershell) the user is currently running. Therefore we need a wrapper script similar like what we had before:
Instead that new script should be quite different:
devon[.bat]
it should be namedide[.bat]
ideasy[.exe]
(our native image from GraalVM) passing exactly those arguments the user had given. This can log output and interact with the user via CLI as usual.ideasy[.exe]
again withenv
as argument to trigger theEnvironmentCommandlet
. In case we are running from bash (and we are on windows), then a second parameter--bash
shall be supplied (ideasy env --bash
). The output of this should be evaluated in an analogue way as we did to load thedevon.properties
in Bash/CMD (https://github.com/devonfw/ide/blob/master/scripts/src/main/resources/scripts/functions-core#L9). Maybe we can even do KISS and redirect the entire env output to a pipe calling theeval
command.To simplify things you may develop and provide
ide
(bash) andide.bat
in separate steps as individual PRs. As those files need to be included into our release package. My suggestion would be:cli/src/main/package
cli/pom.xml
with abuild/resources
section that copies (and filters) the files from that folder to something liketarget/package
. Please properly use maven variables instead of hardcodedtarget
folder (that may be redirected e.g. toeclipse-target
).package.xml
) to ensure that thetarget/package
folder is finally archived to our tar.gz file for the release.target/package/bin/
). Also rename the native image toideasy[.exe]
as otherwise we have a name clashing between theide
wrapper script and theideasy
(native image binary).Again if you want to simplify. You can first place the scripts into the new location as a PR (first bullet point above) and later create a PR to integrate it and improve the release package.
Clarification of potential questions:
ide[.bat]
script find the native binary? The most simple approach that I can think of would be that we have a central installation of IDEasy, that is inside IDE_ROOT that could be set as a global environment variable on the initial installation and always be on the PATH (${IDE_ROOT}/bin
so e.g.D:\projects\_ide\bin
) so we do not have to look for it (we have already agreed on this approach). However, the implication would be that if you install an update, you will update the CLI globally on your machine. If there are (breaking?) changes, this will apply to all IDE installations. An alternative would be to keep the old logic to find IDE_HOME in the script and have the ide-cli in abin
(orscripts
) folder in IDE_HOME. After using devonfw-ide for years and having many parallel IDE instances I learned that updating is kind of tedious as I have to run theide update scripts
more than 10 times until all my installations are up-to-date. Therefore a global installation would be my first thought. Also this avoids redundancy and waste of disk-space if theide-cli.exe
is already 55MB. IMHO we just need to learn more about caring for downward compatibility and then this approach should be fine.