@doublefx
Thanks for testing! This must be quite frustrating.
Running is supposed to work the same way as debugging.
If no interpreter is defined in the run configuration, then the default defined at File > Settings > Languages&Frameworks > BashSupport Pro is picked up. The applied path mapping is defined there in the settings. If an interpreter is defined, then the path is looked up in that list to find the path mapping to apply.
I may have published an old version somehow, there were more troubles with the eap last week.
I’m currently in the midst of forking the JetBrains Shell plugin and adding a run configuration type, which is providing a better UI for the path mapping, the interpreter setup, etc. This will hopefully solve the confusing complexity of the run configuration setup.
I’ll post an update here when I have a new preview version.
Thanks!
Joachim
Hi @jansorg
I don’t know whether you already thought about it but now you’ve added an interpreter list in the settings, what do you think about adding the same action than “Open in terminal” but powered by this new feature, something like “Open in terminal…” where the user could choose one of the configured interpreters.
I’m pretty sure I’ll be far to be the only one who would love it, actually, I was hoping that BashSupport had this feature before even trying it and that was therefore the main reason for me to try it but last week end I discovered the debugger and that’s really, really great too 
Regards,
Fred.
PS: I’ll be testing your new preview in the weekend, if you can made it available by then.
Hi @doublefx,
I’m glad that at least the debugger is working so fa
An settings to control which interpreters should be shown in the menus sounds useful to me.
Could you explain why you’d like to use this feature? That would help to make this to work as expected.
For example
- is the main reason that you usually run scripts with different interpreters?
- Is it important that it’s executed in the cmder terminal window or could that be a regular run configuration window, too? A regular run configuration window won’t accept further input when the script terminates.
- or are you just running a lot of scripts and would like to avoid to create many temporary run configurations? currently “Run in terminal” does not create new configurations.
I still have sort out a few more issues with the plugin, so most likely it won’t be available this weekend.
I posted the current status of run configurations at Status of new run configurations.
Thanks,
Joachim
@doublefx
This is what I have now (unreleased):
- a setting “Show in menus” in the rows of table of interpreters, off by default
- the default run, debug, create/edit at the top
- then for each interpreter with “show in menus” enabled, the available actions.
Does that seems like something useful for your use case?
I still have to integrate this with the windows path mapping settings.
The difficulty of “Run in terminal” to know what mapping to apply. cmd and cmder take the native interpreter path, e.g. C:\Windows\System32\cmd.exe. But others, e.g. WSL, need a mapped interpreter path like /cmd/windows/system32/bash.exe.
I’ll think some more about the best way to handle this, but it should be possible somehow.
Hi @jansorg
“Could you explain why you’d like to use this feature? That would help to make this to work as expected.”
My OS is Windows and I constantly need to switch between cmd / ps / wsl / cygwin.
I found a compromise using cmder out of the IDE as my main command line tool, I also integrated it into IJ as a cygwin replacement, that’s not ideal but still better than switching interpreter from inside the default terminal or changing the default terminal settings.
Therefore, in order to easily open a new terminal on either cmd / ps / wsl (zsh) / cygwin or others, an action in the Project window (on folders and scripts) equivalent to the existing “open in terminal” but with the ability to choose one of the configured interpreter would make life much easier.
Regards,
Fred.
Hi @jansorg
That looks good
" The difficulty of “Run in terminal” to know what mapping to apply. cmd and cmder take the native interpreter path, e.g. C:\Windows\System32\cmd.exe . But others, e.g. WSL, need a mapped interpreter path like /cmd/windows/system32/bash.exe .
I’ll think some more about the best way to handle this, but it should be possible somehow."
Can you just add “use mapping” checkbox in the bashPro interpreter settings ?
I know it might not be easy because different interpreters map differently.
Also, the “Highlighting - JetBrains Shell” option gives me:
2020-07-05 08:26:48,909 [ 172622] INFO - xecution.runners.ExecutionUtil - Error running ‘build-run-native-in-wsl.sh’:
Unable to retrieve version of Bash interpreter. Please refer to the logfile for more details.
com.intellij.execution.ExecutionException: Unable to retrieve version of Bash interpreter. Please refer to the logfile for more details.
at pro.bashsupport.n.j.b.a(b.java:173)
at pro.bashsupport.n.f.bz.a(bz.java:98)
at pro.bashsupport.n.f.bz.compute(bz.java:21)
at com.intellij.openapi.progress.impl.CoreProgressManager$1.run(CoreProgressManager.java:245)
at com.intellij.openapi.progress.impl.CoreProgressManager$TaskRunnable.run(CoreProgressManager.java:935)
at com.intellij.openapi.progress.impl.CoreProgressManager$4.run(CoreProgressManager.java:490)
at com.intellij.openapi.progress.impl.ProgressRunner.lambda$new$0(ProgressRunner.java:79)
at com.intellij.openapi.progress.impl.ProgressRunner.lambda$submit$3(ProgressRunner.java:235)
at com.intellij.openapi.progress.impl.CoreProgressManager.lambda$runProcess$2(CoreProgressManager.java:170)
at com.intellij.openapi.progress.impl.CoreProgressManager.registerIndicatorAndRun(CoreProgressManager.java:629)
at com.intellij.openapi.progress.impl.CoreProgressManager.executeProcessUnderProgress(CoreProgressManager.java:581)
at com.intellij.openapi.progress.impl.ProgressManagerImpl.executeProcessUnderProgress(ProgressManagerImpl.java:60)
at com.intellij.openapi.progress.impl.CoreProgressManager.runProcess(CoreProgressManager.java:157)
at com.intellij.openapi.progress.impl.ProgressRunner.lambda$submit$4(ProgressRunner.java:235)
at java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1700)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.util.concurrent.Executors$PrivilegedThreadFactory$1$1.run(Executors.java:668)
at java.base/java.util.concurrent.Executors$PrivilegedThreadFactory$1$1.run(Executors.java:665)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at java.base/java.util.concurrent.Executors$PrivilegedThreadFactory$1.run(Executors.java:665)
at java.base/java.lang.Thread.run(Thread.java:834)
Actually, the “Open in Terminal…” feature might be too complicated to implement and I’ve been playing a bit more with cmder and the new split terminal feature and I’ll be fine I guess with the existing features, I can use bashPro only to debug scripts.
Hi @doublefx, in the meantime I’ve published an uptime, which ships a new type of run configurations and still supports the old BashSupport and Shell run configs.
The editor still has the “Run in terminal” action on the first line. It should hopefully do the path mapping for the configured terminal. If it doesn’t, the exact command configured as terminal interpreter at Settings>Tools>Terminal>Shell path would help to debug this.
Regards,
Joachim
Hi @jansorg
In settings, I enabled Show in Menu, in the Editor, clicked on Debug with Wsl and got:
2020-07-21 08:08:11,223 [ 64644] INFO - xecution.runners.ExecutionUtil - Error running 'build-run-native-in-wsl.sh':<br>Unable to retrieve the version of the interpreter C:\WINDOWS\system32\wsl.exe. Please refer to the logfile for more details.
com.intellij.execution.ExecutionException: Unable to retrieve the version of the interpreter C:\WINDOWS\system32\wsl.exe. Please refer to the logfile for more details.
at pro.bashsupport.zq.a(zq.java:196)
at pro.bashsupport.sj.a(sj.java:97)
at pro.bashsupport.sj.compute(sj.java:19)
at com.intellij.openapi.progress.impl.CoreProgressManager$1.run(CoreProgressManager.java:245)
at com.intellij.openapi.progress.impl.CoreProgressManager$TaskRunnable.run(CoreProgressManager.java:935)
at com.intellij.openapi.progress.impl.CoreProgressManager$4.run(CoreProgressManager.java:490)
at com.intellij.openapi.progress.impl.ProgressRunner.lambda$new$0(ProgressRunner.java:79)
at com.intellij.openapi.progress.impl.ProgressRunner.lambda$submit$3(ProgressRunner.java:235)
at com.intellij.openapi.progress.impl.CoreProgressManager.lambda$runProcess$2(CoreProgressManager.java:170)
at com.intellij.openapi.progress.impl.CoreProgressManager.registerIndicatorAndRun(CoreProgressManager.java:629)
at com.intellij.openapi.progress.impl.CoreProgressManager.executeProcessUnderProgress(CoreProgressManager.java:581)
at com.intellij.openapi.progress.impl.ProgressManagerImpl.executeProcessUnderProgress(ProgressManagerImpl.java:60)
at com.intellij.openapi.progress.impl.CoreProgressManager.runProcess(CoreProgressManager.java:157)
at com.intellij.openapi.progress.impl.ProgressRunner.lambda$submit$4(ProgressRunner.java:235)
at java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1700)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.util.concurrent.Executors$PrivilegedThreadFactory$1$1.run(Executors.java:668)
at java.base/java.util.concurrent.Executors$PrivilegedThreadFactory$1$1.run(Executors.java:665)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at java.base/java.util.concurrent.Executors$PrivilegedThreadFactory$1.run(Executors.java:665)
at java.base/java.lang.Thread.run(Thread.java:834)
2020-07-21 08:10:08,282 [ 181703] INFO - ution.rmi.RemoteProcessSupport - Terminating: 35581/Maven36ServerImpl671be71a
Run in Terminal (using Cmder):
2020-07-21 08:10:08,282 [ 181703] INFO - ution.rmi.RemoteProcessSupport - Terminating: 35581/Maven36ServerImpl671be71a
2020-07-21 08:10:25,964 [ 199385] INFO - rationStore.ComponentStoreImpl - Saving appVisualizationTool took 16 ms
2020-07-21 08:10:26,421 [ 199842] INFO - rationStore.ComponentStoreImpl - Saving Project(name=todo-backend, containerState=ACTIVE, componentStore=C:\dev\source\my\demo\quarkus-deep-dive)RunManager took 22 ms
2020-07-21 08:12:09,358 [ 302779] INFO - iment.WebServiceStatusProvider - Completion stats experiment: version=2, enabled=false
2020-07-21 08:12:37,695 [ 331116] INFO - xecution.runners.ExecutionUtil - Error running 'build-run-native-in-wsl.sh':<br>Trailing char < > at index 3: cmd /k C:\tools\Cmder\cmder_shell.bat
java.nio.file.InvalidPathException: Trailing char < > at index 3: cmd /k C:\tools\Cmder\cmder_shell.bat
at java.base/sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:172)
at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153)
at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77)
at java.base/sun.nio.fs.WindowsPath.parse(WindowsPath.java:92)
at java.base/sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:229)
at java.base/java.nio.file.Path.of(Path.java:147)
at java.base/java.nio.file.Paths.get(Paths.java:69)
at pro.bashsupport.ad9.a(ad9.java:18)
at pro.bashsupport.vi.execute(vi.java:21)
at com.intellij.execution.runners.DefaultRunProgramRunner$execute$1.invoke(DefaultRunProgramRunner.kt:29)
at com.intellij.execution.runners.DefaultRunProgramRunner$execute$1.invoke(DefaultRunProgramRunner.kt:12)
at com.intellij.execution.impl.ExecutionManagerImpl$startRunProfile$1.invoke(ExecutionManagerImpl.kt:147)
at com.intellij.execution.impl.ExecutionManagerImpl$startRunProfile$1.invoke(ExecutionManagerImpl.kt:60)
at com.intellij.execution.impl.ExecutionManagerImpl$doStartRunProfile$startRunnable$1.run(ExecutionManagerImpl.kt:208)
at com.intellij.openapi.application.TransactionGuardImpl$2.run(TransactionGuardImpl.java:201)
at com.intellij.openapi.application.impl.ApplicationImpl.runIntendedWriteActionOnCurrentThread(ApplicationImpl.java:802)
at com.intellij.openapi.application.impl.ApplicationImpl.lambda$invokeLater$4(ApplicationImpl.java:322)
at com.intellij.openapi.application.impl.FlushQueue.doRun(FlushQueue.java:84)
at com.intellij.openapi.application.impl.FlushQueue.runNextEvent(FlushQueue.java:132)
at com.intellij.openapi.application.impl.FlushQueue.flushNow(FlushQueue.java:47)
at com.intellij.openapi.application.impl.FlushQueue$FlushNow.run(FlushQueue.java:188)
at java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:313)
at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:776)
at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:727)
at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:721)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85)
at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:746)
at com.intellij.ide.IdeEventQueue.defaultDispatchEvent(IdeEventQueue.java:967)
at com.intellij.ide.IdeEventQueue._dispatchEvent(IdeEventQueue.java:839)
at com.intellij.ide.IdeEventQueue.lambda$dispatchEvent$8(IdeEventQueue.java:450)
at com.intellij.openapi.progress.impl.CoreProgressManager.computePrioritized(CoreProgressManager.java:744)
at com.intellij.ide.IdeEventQueue.lambda$dispatchEvent$9(IdeEventQueue.java:449)
at com.intellij.openapi.application.impl.ApplicationImpl.runIntendedWriteActionOnCurrentThread(ApplicationImpl.java:802)
at com.intellij.ide.IdeEventQueue.dispatchEvent(IdeEventQueue.java:497)
at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203)
at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124)
at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113)
at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109)
at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90)
2020-07-21 08:13:18,157 [ 371578] INFO - rationStore.ComponentStoreImpl - Saving appNotificationConfiguration took 15 ms
2020-07-21 08:13:18,223 [ 371644] WARN - com.intellij.util.xmlb.Binding - no accessors for org.jetbrains.kotlin.idea.core.script.configuration.utils.ScriptClassRootsStorage
2020-07-21 08:13:18,239 [ 371660] INFO - rationStore.ComponentStoreImpl - Saving Project(name=todo-backend, containerState=ACTIVE, componentStore=C:\dev\source\my\demo\quarkus-deep-dive)IdeDocumentHistory took 15 ms, RunManager took 16 ms
Also, enabling / disabling “Show in menus” is not effective until restart
Thanks,
Fred.
Hi @doublefx, thanks for your patience.
I’ve published an update which should fix the issues you noticed.
Fixed. wsl.exe is a bit special and should now be handled properly.
Should be fixed. I couldn’t fully reproduce this, most likely because my cmder_shell.bat file is different.
If it still fails, then there’s a new setting to override the path mapping, which is needed for “Run in terminal”. You can find it at “Settings > Languages & Frameworks > BashSupport Pro” below the table of interpreters. “None” is the value if you need Windows native paths, e.g. C:\Windows\System32\wsl.exe.
Please let me know if this is still isn’t working properly.
Fixed, thanks!
Regards,
Joachim
