Setup can't find Bash nor Git

[JSGitHubbing]

Expected behavior

I wanted to setup the devonfw ide with its setup.bat

Actual behavior

setup.bat doesn't recognize my Git for windows nor bash

As we can see it is intalled

And the environmente variable is set

Steps to reproduce (bug)

1. With cmd or GitBash open setup.bat

In the previous screenshot it may seem that devonfw-ide-scripts-3.2.3.tar is not a folder but it is the name of the folder where I have the setup.bat

Affected version: 3.2.3

• OS: Windows

[salfuve]

Could you try to execute it without the ".bat"?Something like this:
$ ./setup

[JSGitHubbing]

It works now, thanks!

[jdiazgon]

As far as I understand, this issue should be reopened because you had to use the Linux batch file (setup) instead of setup.bat because it was not properly working.

The solution posted here is a workaround, but setup.bat should work out of the box.

[hohwille]

Further, it is strongly recommended to use the official git for windows with git-bash rather than a custom installation. This is how we test on windows and how we guarantee that it is working.
Finally, if you just double click the setup script from your "file-manager" it will work on all platforms as you can not run the wrong script then since only the "right one" is executable.
Feel free to provide PRs for further improvements and better auto-detections.
For the moment this is considered done as it is not a bug and turned out to work.

[hohwille]

Finally, I would strongly suggest to read and follow the documentation.
Windows has severe issues with long paths, whitespaces in paths, etc.
Therefore we say you should use something like C:\projects rather than %USERPROFILE%/Desktop/MisProyects/Spring. We can not support anything if you do not follow these recommendations. RTFM or watch the video on youtube.

[jdiazgon]

Finally, if you just double click the setup script from your "file-manager" it will work on all platforms as you can not run the wrong script then since only the "right one" is executable

Actually, that is exactly what we tried. setup.bat was not working even after installing the official Git for Windows (and we obviously rebooted). I have seen this exact issue on at least 2 users and seems to me like a bug. I think the way to reproduce it is:

1. Take a fresh Windows machine without Git for Windows installed.
2. Download devonfw-ide and run setup.bat
3. You install Git for Windows.
4. devonfw-ide still throws the same issue. Is there any config file that blocks devonfw-ide to check the environment variables?

[Jorge-Dacal]

I tried it and setup.bat not work on a fresh windows machine.

Finally I found the workaround posted here. I needed to open the gitbash manually and execute setup instead of setup.bat. setup.bat showed the next error:

[dglezrez]

I had the exact problem as @JSGitHubbing and @Jorge-Dacal explained. I had to create CYGWIN_HOME environment variable to make it work.

[Jorge-Dacal]

It wasn't working for me so I uninstalled everything and started again.

Apparently, I must have had an error with my Git installation, after uninstalling and installing it again works correctly.

The solution seems to Install git with right-click and run as admin, and be careful because it asks many times for permission.

[markusschuh]

After all devonfw-ide needs a bash to run. Since bash isn't a per default fulfilled prerequisite on Windows (not yet) there are two approaches:

• Either the user starts the bash. Then every bash script - but not windows scripts (ending in .BAT or .CMD`) - can just use this current bash.
• Or the user starts the setup.bat. In that case - independently of however this setup.bat was started - the setup.bat (or better the called scripts\devon.bat has a hard job to locate any bash on the Windows host.

Especially since on Windows there exists many different ways to emulate a unix environment with a bash. The current implementation of scripts\devon.bat only supports two of those many cases - probably the most widespread used ones . But currently the "Git-for-Windows"-Installer installation is only clearly detected, when executed the "standard" way:
Started as a standard user - and being able to successfully answer an UAC prompt - which may be shown.

I assume, the detection logic can be expanded to the case, where this prompt is canceled - and git-for-windows is then installed in a path, where user can write. But the exact logic, how to locate a bash on Windows with help of a windows-batch first needs to be tested and implemented within devonfw-ide .

Up to then, most users might detect that the "natural" procedure

1. start bash
2. switch to the path where devonfw-ide was extracted
3. start setup

works. Also in cases, where git was not installed with admin rights.

If you want that to be more convenient in such not-yet-supported cases help the community to support more setup variants of bash under Windows. In case the scripts\devon.bat script code will be changed to detect more setup variants, this needs some testers, which have access to their special Windows setups. Only then those changes can be released to everybody.

N.B.: I personally would try to avoid to run the git installer itself as admin if any possible. This isn't a recommend procedure on windows for any installation. But true - unfortunately some insane configured company security controls force users to use such non-recommend installation procedures.

[jdiazgon]

IMHO I would completely remove setup.bat and leave setup that will be executed with Git bash in Windows:

• In Windows setup.bat is causing several issues, which results in poor user experience (One Sogeti manager faced this issue on a live demo).
• In Windows anyway you need to install Git bash (it is a prerequisite).
• In Windows it seems setup works well when executing it using a Git bash.
• Removing setup.bat will reduce maintainance efforts.

What do you think?

[markusschuh]

First: Fixing the issue described here, seems meanwhile simple enough to me: I have tested the installation of Git for Windows - and Cygwin - as another user, which is denied access to "Local Administrative" rights. In that case the registry settings that help other programs to locate the root directory (of git-for-windows - or cygwin) are indeed created at HKEY_CURRENT_USER - and not under HKEY_LOCAL_MACHINE. I can prepare a PR for that - my first try only had an issue with the goto, which has some limitation in nested loops under Windows batch.

Of course even when this is fixed there are still setups, that will lead into similar issues - e.g. if somebody installs the portable version of Git-for-Windows there is no real chance to detect this automatically (other than wild guessing) Of course some additional command line option for the setup could make it easier for the user to provide a specific bash location.

Second: With respect to your, @jdiazgon, proposal to remove the setup.bat:

1. The issue is not in setup.bat. It is in scripts\devon.bat. Of course it could be decided to fully remove and "native Windows" support from devonfw-ide and such force any user to mandatory use the git-bash on Windows. While git-bash is nice it isn't perfect - and not usable for everybody. Development under Windows works quite fine also outside of any bash, also. In that sense, I'd say, removing the "non-bash setup` only because it is not 100% perfect seems to be too drastic for me.

2. Why not rename the two scripts a bit instead? Keeping script files with generic names as setup / setup.bat in such a prominent place (top dir of devonfw-ide installation root directory) anyway seems not correct for me. This has an - even when low - risk, the user executes the "setup" later again by chance. Why not use setup_devonfw-ide_for_bash_shell and setup_devonfw-ide_for_CMD.bat

[hohwille]

So thanks for insisting on this bug and reopening. After all we can agree that there is a problem and we should find a way to improve reliability.

IMHO I would completely remove setup.bat

You have not enough insights about devonfw-ide to understand the implications. You would need to look into the scripts and how things work. Also on windows we invested quite some energy to get deeper integration (e.g. into explorer) that does not happen if you run setup (without setup.bat).
Same what @markusschuh was saying with 1.

2. Why not rename the two scripts a bit instead?

I strongly disagree here. This is not solving the actual problem here. We would have to rewrite significat portions of the documentation, cause a lot of confusion to existing users, modify the update process, etc.
And we are comming from this mess. oasp4j-ide was shipped with many scripts with long and unintuitive names. We wanted to have a solution that is simple. Run the setup and you are ready to go. All other x-platform projects work this way. In maven you run mvn - on windows it is mvn.cmd or mvn.bar while on other platforms it is a mvn bash script that is executable.

So let us solve the actual problem by trying even harder to figure out where to find (git) bash. I have no time to prioritize this at the moment. If someone wants to contribute, it would already help very much to copy the portion from our scripts to detect bash into a new .bat file that only prints the detected bash path. Then post your solution in this issue and we can easily take over from there.

[jdiazgon]

Thanks for your comments, now I can understand why you do not want to remove setup.bat.

2. Why not rename the two scripts a bit instead?

As Jörg said, this does not seem the solution to the problem.

[markusschuh]

The issues, that non-admin installation of GitForWindows (or Cygwin) wasn't detected yet is fixed by the PR.

The issues that setup and setup.bat - a superset of setup - have the same base name but execute quite some different changes to the machine is not solved by this PR. For me the only reason, I consider this also an issue here, is since the devonfw-ide claim is it were simple and would solve all typical developer problems. Experienced users might not even have tried to run a setup.bat within a Git Bash - but since the MSYS2 environment of GitForWindows - meanwhile - support this. Why not? I expect a similar mix up will appear again - and just answer related new issues with RTFM comments is IMHO not the right approach - under the current claim.

[hohwille]

@markusschuh thanks for your PR that I already merged. So the main problem is solved.

For the scripts I would suggest to simply add a trivial OS check to setup and make it fail on Windows (or even automatically invoke setup.bat to be executed in CMD). Once this is done we can close this issue. Prioritiy is already lowered.

[markusschuh]

When MSYS2 ( git bash) or cygwin execute ˋsetup.batˋ they run it within a forked CMD process - so it isńt that easy to differentiate this case from when it is started within. explorer. But I see one difference in the environment which allows to support also the case, when somebody only has installed the portable git-for-windows: As long as the ˋsetup.batˋ is started from within a bash there is a ˋSHELLˋ set within environment inherited from parent process.

Using this - with higher priority over the registry detection - to locate the ˋbashˋ for execution of ˋdevonˋ makes sense. Íll prepare another PR for this case.

This alltogether should resolve this current issue to only the — still rare — case, when somebody uses the Windows 10 ( more recent releases) ˋ%SystemRoot%\system32\bash.exeˋ. But WSL / WSL2 is another challenge anyway - and not so relevant for the moment in context of ˋdevonfw-ideˋ .

[hohwille]

We could even introduce a variable BASH_HOME (or DEVON_BASH_HOME) that would be honored by devon.bat if set. So users in such special situations can simply "assist" devonfw-ide to find bash by configuring the proper path manually in %USERPROFILE%/devon.properties.

[hohwille]

So actual fix was provided by @markusschuh via PR #360. To finally close this issue I created and merged #388.