Launch xpm in a PTY

[jonahgraham]

By launching in a PTY the bash -i won't have its stdin connected to the stdin of Eclipse, meaning it will properly behave and not stop with a SIGTTIN when bash tries to read.

Fixes #626

[jonahgraham]

This seems to be the correct fix. But I am letting this build on CI so that I can have a p2 to install on multiple machines easier to facilitate testing. This works in my linux dev environment when launched from a terminal or from a UI.

This is building on Jenkins now and will be ready as a p2 site in a little while here: https://download.eclipse.org/embed-cdt/builds/launch-xpm-in-pty/

I will progress this again tomorrow.

@ilg-ul Once I have tested this I will let you know so you can test in your environment too.

[ilg-ul]

I checked the new p2 site and it was ok on my RPi5, with Eclipse started both in a terminal or from the file manager.

Can you help me understand your solution?

[ilg-ul]

This works in my linux dev

Just to be sure, did you install node/npm via nvm, as instructed?

[jonahgraham]

Just to be sure, did you install node/npm via nvm, as instructed?

Yes.

[jonahgraham]

I have tested it by installing https://download.eclipse.org/embed-cdt/builds/launch-xpm-in-pty/p2/ into Eclipse IDE for Embedded C/C++ developers 2026-02 M2. Without the update it hangs (when launched from terminal) and with the update it creates project as expected.

I will now test on a Windows (and maybe a macOS machine if I can borrow one).

Can you help me understand your solution?

ProcessFactory.getFactory().exec() without a PTY will inherit the /dev/tty from the parent process. When launching bash with -i it will try to open /dev/tty. A process cannot access /dev/tty if it is not the foreground process of that terminal, so instead it raises SIGTTIN stopping bash (and hence xpm).

By adding the PTY argument (PTY.isSupported(Mode.TERMINAL) is always true on Linux) the process will be connected to a new PTY and that means /dev/tty will be connected to that PTY instead of the terminal's one.

This allows launching xpm under the bash -i successfully.

[jonahgraham]

Note that SIGTTIN is raised on the process group, so #649 actually made things worse because launching with ProcessBuilder keeps the launched process in the same process group, causing Eclipse itself to be stopped. ProcessFactory makes a new process group, so only the bash/xpm is stopped.

[ilg-ul]

To summarise: bash -i is required by run nvm initialisation script. With this option, bash does an access to stdin. In the initial Eclipse implementation the process did not have a PTY, and bash received a SIGTTIN that terminated it.

With the new implementation, this no longer happens, and bash can proceed with launching xpm.

It would be also interesting to know why this happened only when launching Eclipse from a terminal.

[jonahgraham]

It would be also interesting to know why this happened only when launching Eclipse from a terminal.

Because when launched from a terminal there is a /dev/tty that bash can open (but then not access because it is not the foreground process). When launched from a UI it is launched in a detached state meaning no /dev/tty and all good.

BTW have you tested launching on mac from a terminal? With bash shell?

---

Anyway, my windows test failed :-( I am going to change the condition to be to use the new code path explicitly just on Linux. I was hoping the supports terminal check would be best as most of the time windows and mac supports terminal. But since the pre-existing code works on Windows (and mac?) I will make the change OS specific.

[ilg-ul]

I will make the change OS specific.

I suggest you keep the initial implementation only on Windows and apply the new patch on both Linux and macOS.

I did not test with bash on macOS, but I'll test it as soon as you have a new set of binaries.

[jonahgraham]

The current released code does indeed fail on macOS when Eclipse is launched from a terminal (SHELL=zsh). I see zsh is in T (stopped) process state.

Ironically I cannot test it when launching Eclipse from the finder because when I do that it doesn't find xpm at all, because it isn't running ~/.zshrc! I get Template Engine error: [zsh:1: command not found: xpm]. I will spend a moment trying to figure out why while the build completes on CI.

[ilg-ul]

The nvm documentation states that after you run the install script you have to exit the terminal and create a new one, to allow it to run the .bashrc/.zshrc. If you need to run in the same terminal you have to manually execute the two lines that are added to the rc file, to set the node environment.

[jonahgraham]

It was because the macOS laptop I borrowed already had everything setup with brew and I wasn't at liberty to change things that much. And brew relies on ~/.zprofile aka zsh --login to work.

[ilg-ul]

Well, brew is not the most fortunate solution since it installs everything with root rights, and npm/xpm are not happy with this.

The main trick with nvm is that everything is installed within user home folder, and can also be removed simply by removing the folders, without any system rights.

[jonahgraham]

I tested on Windows + macOS (terminal launching of Eclipse only as per #650 (comment)) + Linux (terminal and GUI launching of Eclipse)

It works in all those environments AFAICT.

@ilg-ul if it works for you please go ahead and merge. I can look again tomorrow if there are still outstanding issues.

---

For clarity, I tested this wizard entry with all default values on the subsequent pages:

On Linux and Windows I used to setup instructions as listed https://eclipse-embed-cdt.github.io/plugins/prerequisites/. For macOS I installed xpm with the node/npm already present on the machine.

I have tested it by installing https://download.eclipse.org/embed-cdt/builds/launch-xpm-in-pty/p2/ into Eclipse IDE for Embedded C/C++ developers 2026-02 M2.

To make sure you have the correct version of the PR, the feature versions should be 6.7.0.202602122152

[ilg-ul]

As you correctly predicted, the problem also affected macOS, just that on macOS the binary is hidden inside the .app folder and few, if any, start it in a terminal.

I tested the current patch on 2026-02-m2 and it is functional on Raspberry Pi5 and Intel Mac Mini.

please go ahead and merge

You mean the green 'Squash and merge' button, right?

Tomorrow I'll be away from my computer most of the day, but I'll be back in the evening, and, if you confirm it, I can merge it. I hope it isn't too late for your release schedule.