Ability to uninstall devon-ide

[hohwille]

The main setup[.bat] script delegates to devon ide setup what "installs" the devon-ide.
As devon-ide aims to be portable and minimal invasiv to your OS it only does little tweaks on your system. However, there are some:

• ~/.devon folder
• ~/scripts/devon.bat (on windows)
• adding ~/scripts to your PATH (on windows)
• Windows registry entries for explorer integration (e.g. system/windows/cmd/*.reg)
• MacOS workflows for finder integration

A good pice of software should always provide an automated way to "uninstall" itself if the user does not want to have it anymore. Also this might be a way to repair or upgrade an installation if the according central scripts or hooks may have changed.

[markusschuh]

Wrt to removal of the registry value:
If devon-ide would use its own directory key - named "devonfw" - the removal would be just a
"%Systemroot%\system32\reg delete HKCU\Software\Classes\Folder\shell\devonfw /f

But the registry key used so far within the devon-cmd.reg makes it a bit harder:

1. it uses "HKCR". This is the logic "unified" registry path which mixes administrative and user keys within one tree. It can be used for write - but the resulting path depends on the current right level of the user. So most already written keys will have been saved at
   HKCU\Software\Classes\Folder\shell\cmd
   but some may have beend saved at
   HKLM\Software\Classes\Folder\shell\cmd

2. The subkey "cmd" should match to the specific application using it. Quite some application define their own subkeys (though many may use Classes\Directory instead, which is the same as Folder - but matched for directories on local filesystems only). The "cmd" could be used by others - so it would be more friendly in this case to not remove the whole tree without another check, the values saved there are as expected.

I favorize to also change the setup of this explorer integration to be realized in its own key at user level:

"%SystemRoot%\system32\reg" add HKCU\Software\Classes\Folder\shell\devonfw\command
"%SystemRoot%\system32\reg" add HKCU\Software\Classes\Folder\shell\devonfw /ve /t REG_SZ /d "Open Devon CMD here" /f
"%SystemRoot%\system32\reg" add HKCU\Software\Classes\Folder\shell\devonfw\command /ve /t REG_SZ /d "cmd.exe /s /k pushd \"%V\" && devon" /f

but in that case it may still be necessary to write some "remove keys from older oasp / devon" versions.

[hohwille]

Uninstalling devon-ide...
/c/projects/beta3-latest/scripts/command/ide: line 92:  grep: command not found
/c/projects/beta3-latest/scripts/command/ide: line 96:  grep: command not found

https://github.com/devonfw/devon-ide/blob/a4d8c37dd391121d07e8620f52308169a80ebf1d/scripts/src/main/resources/scripts/command/ide#L83

[hohwille]

Running git-bash manually:

$ grep
Usage: grep [OPTION]... PATTERN [FILE]...
Try 'grep --help' for more information.

So the only explanation for the above bug I have is that the PATH was broken/wracked.

[hohwille]

@markusschuh I added devon specific values for the registry.
I am also happy with changing from HKCR to HKCU, but we need a new PR for this.

[hohwille]

For this grep: command not found error it is also very magically:

➜  devon cat ~/.bashrc | grep -v '^alias devon="source ~/.devon/devon"$' | grep -v '^devon$'
. ~/.profile
➜  devon cat ~/.bashrc | grep -v '^alias devon="source ~/.devon/devon"$' | grep -v '^devon$'
zsh: command not found:  grep

The 2nd line was copy & pasted from the script. The first line was typed manually visually copying from the script. Seems as there is some magic unicode character in the word grep that looks exactly like its Latin variant.

[hohwille]

It is not a different character. This is totally wired. I have seen really strange bugs and effects in my life but this one has definetly potential to entre my top 10.

The two lines are exactly identical. Now that I copy them from this github issue in my shell both are working. Still when copying again from the script I get the error again.
May still an invisible unicode character - still clueless...

[hohwille]

This is the most crazy piece of black magic:

➜  devon cat ~/.bashrc | grep -v '^alias devon="source ~/.devon/devon"$' | grep -v '^devon$'
. ~/.profile
➜  devon cat ~/.bashrc | grep -v '^alias devon="source ~/.devon/devon"$' | grep -v '^devon$'
. ~/.profile
➜  devon cat ~/.bashrc | grep -v '^alias devon="source ~/.devon/devon"$' | grep -v '^devon$'
zsh: command not found:  grep
➜  devon cat ~/.bashrc | grep -v '^alias devon="source ~/.devon/devon"$' | grep -v
zsh: command not found:  grep
➜  devon cat ~/.bashrc | grep -v '^alias devon="source ~/.devon/devon"$' | grep
zsh: command not found:  grep
➜  devon cat ~/.bashrc | grep -v '^alias devon="source ~/.devon/devon"$'
. ~/.profile
➜  devon cat ~/.bashrc | grep -v '^alias devon="source ~/.devon/devon"$' | grep -v foo
. ~/.profile
➜  devon cat ~/.bashrc | grep -v '^alias devon="source ~/.devon/devon"$' | grep -v '^devon$'
. ~/.profile

[hohwille]

OK, got it. Seems I was not so clueless as it really was a special unicode character immediately after the pipe symbol that looked like a regular whitespace but was not.

[hohwille]

All fixed except the last remaining issue:

• if used on windows in combination with cygwin then the installation (~/.devon, ~/.bashrc, ~/.zshrc) to cygwins home (C:\cygwin\home\«mylogin») will not yet be uninstalled.
• A proper solution would be coupled to Increase detection probability of installed git, cygwin and potentially more #70. However, for simplicity I would just duplicate the current hack to complete and close this issue and leave it up to Increase detection probability of installed git, cygwin and potentially more #70 to improve the path detection via registry.

[hohwille]

Done