#881: add self healing feature to add x-flags before running command

[hohwille]

fixes #881

[hohwille]

I do not get why the tests fail here.
On Windows they succeed but X-flags are not considered on Windows, so the feature is only really tested on Linux or Mac...
But when I test on my ubuntu, I can see that eclipse binary has all x-flags set after fresh ide install eclipse:

hohwille@CE49454:~/projects/IDEasy$ ls -la software/eclipse/eclipse
-rwxr-xr-x 1 hohwille hohwille 90144 Jan  6 13:48 software/eclipse/eclipse
hohwille@CE49454:~/projects/_ide/software/default/eclipse/eclipse/2024-09$ ls -la eclipse
-rwxr-xr-x 1 hohwille hohwille 90144 Jan  6 13:48 eclipse

So why do we get this error then?

[ERROR] com.devonfw.tools.ide.tool.eclipse.EclipseTest.testEclipse(String)[1] -- Time elapsed: 0.010 s <<< ERROR!
java.lang.IllegalStateException: End of answers reached!
	at com.devonfw.tools.ide.context.AbstractIdeTestContext.readLine(AbstractIdeTestContext.java:87)
	at com.devonfw.tools.ide.context.AbstractIdeContext.question(AbstractIdeContext.java:726)
	at com.devonfw.tools.ide.context.IdeContext.question(IdeContext.java:176)
	at com.devonfw.tools.ide.io.FileAccessImpl.makeExecutable(FileAccessImpl.java:925)
	at com.devonfw.tools.ide.process.ProcessContextImpl.addExecutable(ProcessContextImpl.java:305)
	at com.devonfw.tools.ide.process.ProcessContextImpl.run(ProcessContextImpl.java:153)
	at com.devonfw.tools.ide.context.ProcessContextTestImpl.run(ProcessContextTestImpl.java:25)
	at com.devonfw.tools.ide.tool.ToolCommandlet.runTool(ToolCommandlet.java:169)
	at com.devonfw.tools.ide.tool.eclipse.Eclipse.installPlugin(Eclipse.java:82)
	at com.devonfw.tools.ide.tool.plugin.PluginBasedCommandlet.installPlugins(PluginBasedCommandlet.java:118)
	at com.devonfw.tools.ide.tool.plugin.PluginBasedCommandlet.postInstall(PluginBasedCommandlet.java:104)
	at com.devonfw.tools.ide.tool.LocalToolCommandlet.install(LocalToolCommandlet.java:98)
	at com.devonfw.tools.ide.tool.ToolCommandlet.runTool(ToolCommandlet.java:166)
	at com.devonfw.tools.ide.tool.ToolCommandlet.runTool(ToolCommandlet.java:152)
	at com.devonfw.tools.ide.tool.ide.IdeToolCommandlet.runTool(IdeToolCommandlet.java:55)
	at com.devonfw.tools.ide.tool.ToolCommandlet.run(ToolCommandlet.java:130)
	at com.devonfw.tools.ide.tool.ide.IdeToolCommandlet.run(IdeToolCommandlet.java:49)
	at com.devonfw.tools.ide.tool.eclipse.EclipseTest.testEclipse(EclipseTest.java:40)

See also the log messages before:

19:01:02.152 [main] - INFO  - c.d.tools.ide.log.IdeSubLoggerSlf4j - INTERACTION:We want to execute eclipse but this command seems to lack executable permissions!
Most probably the tool vendor did forgot to add x-flags in the binary release package.
Before running the command, we suggest to set executable permissions to the file:
/home/runner/work/IDEasy/IDEasy/cli/target/test-projects/eclipse/_ide/software/default/eclipse/eclipse/2024-09/eclipse
For security reasons we ask for your confirmation so please check this request.
Do you confirm to make the command executable before running it?
19:01:02.152 [main] - INFO  - c.d.tools.ide.log.IdeSubLoggerSlf4j - INTERACTION:Option 1: yes
19:01:02.152 [main] - INFO  - c.d.tools.ide.log.IdeSubLoggerSlf4j - INTERACTION:Option 2: no

[hohwille]

OK. I added more details and now got this:

13:27:23.060 [main] - INFO  - c.d.tools.ide.log.IdeSubLoggerSlf4j - INTERACTION:We want to execute eclipse but this command seems to lack executable permissions!
Most probably the tool vendor did forgot to add x-flags in the binary release package.
Before running the command, we suggest to set executable permissions to the file:
/home/runner/work/IDEasy/IDEasy/cli/target/test-projects/eclipse/_ide/software/default/eclipse/eclipse/2024-09/Eclipse.app/Contents/MacOS/eclipse
For security reasons we ask for your confirmation so please check this request.
Changing permissions from rw-r--r-- to rwxr-xr-x.
Do you confirm to make the command executable before running it?

So this is because our test resources are lacking x-flags in git. Was wrong from the start but somehow circumvented since we are in Java and not in a shell so we can not run bash scripts directly but only via bash -c so we actually ignore x-flags for bash scripts.

[coveralls]

Pull Request Test Coverage Report for Build 12674280211

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• 90 unchanged lines in 3 files lost coverage.
• Overall coverage increased (+0.06%) to 67.541%

---

Files with Coverage Reduction	New Missed Lines	%
com/devonfw/tools/ide/io/FileAccess.java	2	84.62%
com/devonfw/tools/ide/process/ProcessContextImpl.java	9	79.31%
com/devonfw/tools/ide/io/FileAccessImpl.java	79	64.12%

Totals
Change from base Build 12656121583:	0.06%
Covered Lines:	6670
Relevant Lines:	9533

---

💛 - Coveralls

[jan-vcapgemini]

LGTM. I've tested this feature on my Mac. Removed the execute permissions from my eclipse binary and got the expected prompt. After typing no though, I've got the no permissions exception, maybe we should just stop the process and tell the user that this will not suffice instead of throwing an expected exception which will not help us (user might create a ticket with the provided link). Maybe we should throw a CliAbortException instead.

[hohwille]

LGTM. I've tested this feature on my Mac. Removed the execute permissions from my eclipse binary and got the expected prompt. After typing no though, I've got the no permissions exception, maybe we should just stop the process and tell the user that this will not suffice instead of throwing an expected exception which will not help us (user might create a ticket with the provided link). Maybe we should throw a CliAbortException instead.

Thanks for sharing this observations.
However, there are use-cases where the current behaviour may be desired (e.g. x-flag for group is set and I am in the group but not for others and I also not owner and may have no permissions to change x-flags - so in this case it would still work and the confirmation would be annoying, with CliAbortException it would be impossible to proceed).
I would therefore merge this now and we can then create a new ticket.
Maybe if no x flag is set at all (and it is not a bash script) then on abort we could throw CLiAbortException) - in that case we do not ask at all but in the prior example it would not work if I am not member of the group and still I might have write permission to set x-flags. All edge-case discussion though...