Add support for launching Eclipse Process in a system terminal session

[laeubi]

Currently processes are launched as a forked process without a terminal session attached to them. Some features of processes require a terminal session (e.g. autocompletion) and currently not work when running from within eclipse (e.g. the gogo-shell).

This is an attempt to bring terminal session support to Eclipse to support real terminal application similar to what is supported by IntelliJ.

[laeubi]

Currently if I start gogo-shell with jlink support from within eclipse I get this:

[2025-03-07 17:52:55] [FEIN   ] Error creating EXEC based terminal: Not a tty 
[2025-03-07 17:52:55] [WARNUNG] Creating a dumb terminal 
____________________________
Welcome to Apache Felix Gogo

g!

with this enabled one gets

as one can see the eclipse console does not understand all terminal commands but the ANSI coloring already works and the process runs in a native terminal session.

[laeubi]

If I replace the standard Eclipse Console with jediterm it looks like this:

so colors and auto complete is supported.

[akurtakov]

CDT has a full featured terminal included https://github.com/eclipse-cdt/cdt/tree/main/terminal . It's worth taking a look at it (maybe even reusing parts of it). @jonahgraham do you have some hints here?

[github-actions[bot]]

Test Results

 1 893 files  ±0   1 893 suites  ±0   1h 35m 59s ⏱️ + 9m 45s  4 381 tests ±0   4 357 ✅ ±0   24 💤 ±0  0 ❌ ±0  13 143 runs  ±0  12 976 ✅ ±0  167 💤 ±0  0 ❌ ±0 

Results for commit e1fa9caf. ± Comparison against base commit a02997e9.

:recycle: This comment has been updated with latest results.

[laeubi]

As far as I understand this provides a new view with a terminal where I then can launch some process but it does not integrates with default launches / console views.

I think this would be useful for the console view, lets see if it can be used here...

[laeubi]

BTW I now installed the plugin but it complains UnsatisfiedLinkError: no pty in java.library.path beside from that I can type some commands but do not get a local echo and copy seem also not working.

[jonahgraham]

TM Terminal's control is designed to be embedded in any layout - CDT uses it to provide a terminal interface to GDB for example. TM Terminal's view also uses the control.

jediterm is interesting, it seems more maintained the TM terminal, but I don't know much else. Note that the "pure Java terminal widget" does not extend to support PTY which relies on native code (or JNA for ConPTY). The native code (https://github.com/JetBrains/pty4j) is a fork of org.eclipse.cdt.core.native.

BTW I now installed the plugin but it complains UnsatisfiedLinkError: no pty in java.library.path

If you can explain how to reproduce, please share. The terminal uses org.eclipse.cdt.core.native code to create and manage PTY and subprocesses. If you download any of the EPP packages you can open a terminal to see it there - I am curious if your manual install indicates some dependency/configuration error:

(Note if you are Windows on ARM support was added in CDT 12 being released with 2025-03)

beside from that I can type some commands but do not get a local echo and copy seem also not working.

This is expected behaviour if native part of PTY support doesn't load

[laeubi]

@jonahgraham many thanks for the details I'll try to take a deeper look into that, I just tried yesterday to use the UI part standalone but not with much success, the GDB example looks really handy as a starting point!

While jediterm seem to work quite well the main problem is that is is using Swing, so an SWT alternative would be of course useful, I'm not sure how easy it would be to rewrite only that part.

One thing that currently hinders a smooth integration is that the Console actually want a ConsoleViewer (what is a SourceViewer) with an IDocument. While it seems one could use an IDocument as the "framebuffer" it looks as CDT currently not supporting that.

[laeubi]

I now got it working by open a separate shell and redirecting the streams with some hacking into the debug-plugin:

https://github.com/user-attachments/assets/f3c57127-e534-40a9-b57b-37b758c08310

so far it looks very promising and basic operations work.

So question would be to how proceed here, I could think about having the new API here and let CDT do provide the integration I assume this would then be ProcessFactory. Or we go further with pty4j) as it is quite standalone but if CDT can offer similar I would better integrate this. One drawback is that CDT terminal is not part of platform SDK (@merks ?) so one needs to install it extra for this case.

Another thing is then UI that seems a bit more challenging as we would require a lot more integration points but maybe I just have not found the right place yet.

In general I wonder if it would be useful to bring the console support into platform (maybe as a separate repo) so it could be more tightly integrate.

[laeubi]

If you can explain how to reproduce, please share.

I now found out that I need to explicitly add

• org.eclipse.cdt.core.linux
• org.eclipse.cdt.core.linux.x86_64

to my launch configuration, now it also works in my debugged application.

[laeubi]

I now got it basically working with CDT native (updated the PR here) as well there are just two issue:

1. the factory seems to offer no way to join stdin+stdout (what is a possible option to the debug launch API)
2. the Spawner don't allow access to the PTY instance so I'm not able to dynamically update the terminal size.

[laeubi]

I now was able to show the CDT terminal as a console for the running java process:

https://github.com/user-attachments/assets/c4149ac8-5599-4ff5-a0a2-07465b2d100b

[laeubi]

I now have all puzzle pieces and a fully working solution for terminal support using CDT native, I'll try to create smaller PRs.

@jonahgraham @akurtakov it CDT using "ibuilds" or would one need to wait for the next release to use such new extension points there?

[stbischof]

very interesting. i would like to have!

[laeubi]

@jonahgraham I think actually a tight integration in platform by default would be beneficial. I therefore wonder if we can maybe merge some of the core terminal parts into platform to be provided from there?

This is mainly this bundle here: https://github.com/eclipse-cdt/cdt/tree/main/core/org.eclipse.cdt.core.native + the native fragments, but also the terminal emulation would be interesting.

As an alternative we might consume some dedicated bundles from CDT through the target platform, but this would add yet another inter dependency here.

[jonahgraham]

I therefore wonder if we can maybe merge some of the core terminal parts into platform to be provided from there?

Yes. That is a good idea.

The cdt project adopted the terminal from the tm project to keep it alive(ish) and building. Cdt was a logical home because of the dependency on cdt core native + serial bundle.

But we could move all those bundles to the platform.

[laeubi]

@akurtakov I wonder what would be the best place to move it to. Should we use eclipse.platform? Seems logical related, on the other hand I could also thing eclipse.swt to be a place for this as like it already has for example Program class we could have terminal support there as well.

[akurtakov]

Would you please elaborate on the Program class support a bit more? If SWT is to use it it would should prevent yet another circular dependency at build time.

[laeubi]

Would you please elaborate on the Program class support a bit more? If SWT is to use it it would should prevent yet another circular dependency at build time.

First the code for creating a pty is independent from anything else (thus could be part of SWT) so there is no risk for a circular dependency.

Second we already have native code in SWT and a build infrastructure, and starting a command in a terminal-session looks similar to starting an external process with the TTY (e.g. Program#launchTerminal(String[] cmdLine, File workingDirectory, Map<String, String> environment). We could of course also have a dedicated PTY class there, the main point is if we should add it to SWT project at all.

[akurtakov]

So the proposal is to have extra bundles in swt repo or merge into current SWT bundle/fragments? I am kind of torn here - from one side I don't want to complicate swt build more (maybe it would not at all if in same bundle fragments) on the other replicating the builds in another repo is a problem too and third thing is that this is not strictly UI toolkit thing. Do you care to propose a draft PR for SWT so we can see what would it look like? What do others think?

[laeubi]

I don't think its worth an extra bundle as it does not imply any dependencies. Also I hardly can imagine this to be useful without an UI anyways. I'll try to create a PR to see how it would fit in SWT.

[laeubi]

@jonahgraham I noticed that there is an (optional) dependency for conpty using jna under windows do you know why two impls are supported for windows and what is the advantage of conpty?

[laeubi]

@akurtakov I created a rough PR here that shows how it would look like to merge it into SWT:

• https://github.com/eclipse-platform/eclipse.platform.swt/pull/2025

[jonahgraham]

@jonahgraham I noticed that there is an (optional) dependency for conpty using jna under windows do you know why two impls are supported for windows and what is the advantage of conpty?

conpty is the new way of handing consoles on Windows. winpty is the old way.

This is what I recently said in https://github.com/eclipse-cdt/cdt/issues/969#issuecomment-2552628996 - and now I think is the time to be braver and remove winpty entirely:

The version of winpty is ancient in CDT and when I last tested it it worked fine on a Windows 7 box. The issue is that Windows Console team have been very active in the last few years and it seems the way we (winpty really) is launching the hidden console is not working anymore.

If I was a little braver I would rip out winpty implementation entirely. -Dorg.eclipse.cdt.core.conpty_enabled=false really only existed to ensure that when I first wrote and enabled conpty if I had regressed any user flows we could back out of it. I don't intend to support -Dorg.eclipse.cdt.core.conpty_enabled=false.

Some additional context and links of use for conpty can be found in N&N for CDT https://github.com/eclipse-cdt/cdt/blob/main/NewAndNoteworthy/CDT-10.6.md#windows-pseudo-console-conpty-the-default

[laeubi]

I adopted my example now for latest CDT and latest Platform and it is working as expected. Build will fails as we are missing the required classes currently present at CDT:

• https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/pull/3046

I'll split up some of the UI parts that are independent from this, that can be merged then already.

[laeubi]

Everything is now prepared and merged so this is ready for submission.

[laeubi]

N&N entry is here: https://github.com/eclipse-platform/www.eclipse.org-eclipse/blob/master/news/4.37/platform.md#support-for-launching-a-run-inside-a-terminal-session