Create ide wrapper script

[hohwille]

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 call ide 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:

• CMD: https://github.com/devonfw/ide/blob/master/scripts/src/main/resources/scripts/devon.bat
• Bash: https://github.com/devonfw/ide/blob/master/scripts/src/main/resources/scripts/devon

Instead that new script should be quite different:

• instead of devon[.bat] it should be named ide[.bat]
• it should not contain the logic to find DEVON_IDE_HOME or other things but be even more simplistic:
• first it should check if arguments are given. If that is the case, then it shall call the native 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.
• second it should afterwards always run the native ideasy[.exe] again with env as argument to trigger the EnvironmentCommandlet. 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 the devon.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 the eval command.

To simplify things you may develop and provide ide (bash) and ide.bat in separate steps as individual PRs.
As those files need to be included into our release package. My suggestion would be:

• add the scripts to a folder cli/src/main/package
• adapt the cli/pom.xml with a build/resources section that copies (and filters) the files from that folder to something like target/package. Please properly use maven variables instead of hardcoded target folder (that may be redirected e.g. to eclipse-target).
• Adapt the assembly config exec.xml (also consider renaming to package.xml) to ensure that the target/package folder is finally archived to our tar.gz file for the release.
• Adapt the release and nightly-build process to properly copy the native binaries into the correct places (target/package/bin/). Also rename the native image to ideasy[.exe] as otherwise we have a name clashing between the ide wrapper script and the ideasy (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:

• How can the 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 a bin (or scripts) 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 the ide 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 the ide-cli.exe is already 55MB. IMHO we just need to learn more about caring for downward compatibility and then this approach should be fine.

[hohwille]

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.

[hohwille]

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.

[hohwille]

Already found the source of the bug:

IDEasy/cli/src/main/java/com/devonfw/tools/ide/common/SystemPath.java

Line 109 in 7fcddb5

if (path.startsWith(softwarePath)) {

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:

IDEasy/cli/src/main/java/com/devonfw/tools/ide/common/SystemPath.java

Line 63 in 7fcddb5

for (String segment : envPaths) {

[hohwille]

Maybe we should split this story into 3 aspects:

• ide wrapper script in bash
• ide.bat wrapper script in MS Dos
• bash auto-completion script/function and ability to "install" this to .bashrc and (if present) .zshrc. This one might need to be connected with Implement ability to setup IDE instance #101 and a potential uninstall functionality (no issue created for this yet).

[hohwille]

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.

[hohwille]

Auto-closed by PR #221 but not yet completed:

• We still need a ide.bat script
• We still need bash auto-completion
• We still need something to tweak the .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).

[hohwille]

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:

IDEasy/cli/src/main/java/com/devonfw/tools/ide/context/AbstractIdeContext.java

Line 252 in be4ab47

return "IDE environment variables have been set for " + this.ideHome + " in workspace " + this.workspaceName;

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).