Open file from embedded terminal, easily! #8756

jtulach · 2025-08-23T09:09:36Z

since I am working with VSCode I admire its integration with its embedded shell
I'd like NetBeans terminal integration to be as good
one thing I like a lot is ability to open a file from the terminal

e.g. typing netbeans pom.xml in the embedded terminal would open the file in the IDE the terminal is embedded into
I had such a setup locally for years, but:
- it doesn't work with other than default --userdir well
- not everyone is capable to set it up
thus I've created this PR to provide such a support for everyone

jtulach · 2025-08-23T09:10:48Z

ide/dlight.terminal/src/org/netbeans/modules/dlight/terminal/action/TerminalSupportImpl.java

-                        npb.getEnvironment().put("DYLD_LIBRARY_PATH", "");// NOI18N
-
+                        envVars.put("LD_LIBRARY_PATH", "");// NOI18N
+                        envVars.put("DYLD_LIBRARY_PATH", "");// NOI18N


it was always clear to me I need to set an environment variable to represent the value of --userdir

otherwise the CLIHandler won't be able to connect to the same NetBeans process

originally I thought I will have to make changes here, but ...

jtulach · 2025-08-23T09:12:06Z

nb/ide.launcher/unix/netbeans

@@ -38,6 +38,9 @@ cd "$progdir"/..
 basedir=`pwd`
 cd "$old"

+# make sure own launcher is on PATH
+PATH=$PATH:$progdir


append directory where netbeans launcher is located to the PATH

for all processes launched from the IDE

that way one can type netbeans in the terminal integration

and be sure it is defined

Why append and not prepend? If anyone has netbeans in the PATH, which will include anyone who has installed DEB or RPM versions, and is running an alternative version then this will launch the default instead?

Could also consider an environment variable for the current NetBeans process here? eg. typing $NB pom.xml rather than netbeans pom.xml?

Why append and not prepend?

I wanted to play it safe, but you are right. Inside of NetBeans terminal, it is safer to have the same netbeans executable invoked by default. Fixed in 914565a

typing $NB pom.xml

Typing netbeans feels long, right? I also have a nb symlink and I will update it to point to the right netbeans executable or change it to alias nb=netbeans.

I leave this "shortcutting" out of scope of this PR. The important change is the support for "inheriting user dir". Everything else is easy to script.

typing $NB pom.xml

Typing netbeans feels long, right? I also have a nb symlink and I will update it to point to the right netbeans executable or change it to alias nb=netbeans.

Actually, no, the length wasn't the reason. Putting the executable location in an environment variable rather than messing with the path at all keeps this more self contained and potentially safer.

It might also be good to export the BASEDIR value added in #8408 , although possibly under a NetBeans specific name? That would in most cases be enough to find the launcher, but separate environment variables for current basedir and current launcher locations would be good. That should cover what you need without altering the path for everything else too?

If find the environment variable $NB approach unnatural. I never used something like that before.

Sure, it's unusual, but we need some way that a wrapper script can override this, and that is not path order dependent. Setting the PATH feels a little unsafe and unnecessary, and is going to break in interesting ways away from the zip bundle. The move to prepend rather than append fixes one problem but would introduce another, by bypassing the wrapper script for a system install.

I don't want to do "unusual things" in this PR, thus:

either I revert back to append - it works for me and causes no surprises

or I don't modify PATH at all - hoping netbeans is already on PATH

The move to prepend rather than append fixes one problem

this "problem"?

it is not a problem as far as I can tell

something gets invoked, something happens

once the DEB or RPM launcher honors here in introduced NETBEANS_USERDIR environment variable...

then the behavior will even be exactly as expected

thus I'd say appending is the best way to modify PATH (should this PR modify PATH at all)

Setting an environment variable for the basedir and/or the executable file path isn't unusual. If using it directly feels unusual, then a separate script could be used to do this.

The problem is anything that already puts netbeans on the PATH. If you are running an alternative (zip) version with an appended PATH then you'll get the default install. That may still do the right thing in most cases, once they have a version of NetBeans with the launcher that understands NETBEANS_USERDIR included. I've no idea if other Linux packages play around with userdir, although they may also not put netbeans on the PATH, but the DEB and RPM don't do anything.

If the netbeans location is prepended, then using the installed RPM or DEB packages this would cause calls to netbeans to go directly to /usr/lib/apache-netbeans/bin/netbeans rather than via /usr/bin/netbeans which would in some cases fail due to missing extra configuration.

In all, I have reservations about modifying the PATH, but appending would be less likely to break things while not working in all scenarios. Environment variables feel a little more reliable.

jtulach · 2025-08-23T09:12:57Z

nb/ide.launcher/unix/netbeans

@@ -138,6 +145,8 @@ launchNbexec() {
    then
        sh=/bin/bash
    fi
+    NETBEANS_USERDIR=${userdir}


Store the value of --userdir to a system variable

so that child processes can pick it up

nb/ide.launcher/unix/netbeans

jtulach

any objections against this change?
if no, then TODO:
- document the new environment variable
- modify netbeans.exe to behave the same
let's have a time for inception review now
I plan to get this change into NetBeans 28

neilcsmith-net

I'm in favour of the general principle - in fact I use this feature with the DEB package quite a bit, and alternative userdir support there would be great.

I have a few reservations about the implementation. Our packaging tool works by wrapping the launcher in various ways to meet different OS requirements. Some will already have netbeans in the path. We need to ensure that this works for standalone and installed usage. And I think we need to ensure JAVA_HOME is set in the parent to be picked up in the child process.

neilcsmith-net · 2025-08-23T09:50:26Z

nb/ide.launcher/unix/netbeans

@@ -38,6 +38,9 @@ cd "$progdir"/..
 basedir=`pwd`
 cd "$old"

+# make sure own launcher is on PATH
+PATH=$PATH:$progdir


Why append and not prepend? If anyone has netbeans in the PATH, which will include anyone who has installed DEB or RPM versions, and is running an alternative version then this will launch the default instead?

nb/ide.launcher/unix/netbeans

jtulach · 2025-08-30T09:45:47Z

modify netbeans.exe to behave the same

do I understand correctly I need to make the change in the Propagate NETBEANS_USERDIR environment variable netbeans-native-launchers#12 repository?

neilcsmith-net · 2025-08-30T09:57:22Z

No, the Windows launcher code is back in the main repository. It is built by the workflow at https://github.com/apache/netbeans/blob/master/.github/workflows/native-binary-build-launcher.yml When ready, the version numbers will need updating, binaries built from the workflow, and a release vote done - see #8408 and https://lists.apache.org/thread/491tvp6o44nj9wpmcpbdtcmt8rn0d9h8

EDIT : I'm currently -1 to the PATH modification with prepend. Looking at it I'm not sure we can make that work everywhere it needs to. It will break with some of our packages by bypassing wrapper scripts already in the path. Append is somewhat better (-0.5! 😄 ) but will not work in the cases mentioned earlier. I still think environment variables would be preferable.

Have pinged @matthiasblaesing and @mbien for thoughts. Matthias also ran the last Windows launcher update and vote.

mbien · 2025-08-31T23:51:20Z

I am somewhat mixed on this. On one hand I think that if a terminal behaves differently in the IDE it is essentially a bug (that is also why I think that the launcher should probably not export GDK_SCALE on linux). On the other hand I can see that netbeans could be seen as special kind of program and the utility for it for users who run NB from the zip (I am one of them, but I do have nb already as alias without adding anything to the path, see 4th paragraph).

I am a bit worried about the can of worms this opens (why is javac, mvn, ant etc not in path too etc) and that it is set by default without opt-in or out.

Maybe the solution is to store it in an env var and add a text field to the terminal settings where users can configure path extensions in the sense of PATH:NB_LAUNCHER_PATH. (might have to be hidden on non-unix based systems since cygwin+windows might produce interesting results here and it could have NB_DEFAULT_JDK etc too in future)

I am wondering if PATH is even the right vehicle for this. Letting the NB terminal run alias nb=NB_LAUNCHER_PATH on start might have the smallest risk for side effects and cover the intended usecase.

EDIT : I'm currently -1 to the PATH modification with prepend (..)

I agree, prepend would break existing user setups too, so if at all, it would have to be append IMO.

(slightly related to this proposal would be: path selection -> right click -> open in NB or System for output and terminal as quality of life improvement)

neilcsmith-net · 2025-09-01T17:17:50Z

I am a bit worried about the can of worms this opens (why is javac, mvn, ant etc not in path too etc) and that it is set by default without opt-in or out.

+1

I am wondering if PATH is even the right vehicle for this. Letting the NB terminal run alias nb=NB_LAUNCHER_PATH on start might have the smallest risk for side effects and cover the intended usecase.

I hadn't thought about setting an alias based on the environment variable, but that's a good idea. I think, set up something like NB_BASEDIR and NB_LAUNCHER in the launchers, and the rest can be addressed elsewhere in the codebase over time. It might actually be good to have a customizable script in the userdir that is invoked similarly to ~/.profile and could be used to set up aliases. There's a few other setup things done - here iirc - https://github.com/apache/netbeans/blob/master/ide/dlight.terminal/src/org/netbeans/modules/dlight/terminal/action/TerminalSupportImpl.java#L269

But in the shorter term, the environment variable could still be invoked directly or used to set an alias manually.

Having basedir in there too could allow for pointing aliases at some of those other things you mentioned, should people wish to.

The launcher variable would need to be kept separate to the basedir, and only set if not already configured, so the various package scripts can use it to route through themselves.

and it could have NB_DEFAULT_JDK etc too in future)

Maybe. Some of the packages set JAVA_HOME here, and I think that could be good in the launchers. That does count as a situation where the terminal in the IDE may behave differently to the system mind you (though probably rightly IMO).

Make sure netbeans in terminal means itself

ed6a3f7

jtulach added this to the NB28 milestone Aug 23, 2025

jtulach self-assigned this Aug 23, 2025

jtulach added the Platform [ci] enable platform tests (platform/*) label Aug 23, 2025

jtulach commented Aug 23, 2025

View reviewed changes

nb/ide.launcher/unix/netbeans Show resolved Hide resolved

jtulach commented Aug 23, 2025

View reviewed changes

neilcsmith-net reviewed Aug 23, 2025

View reviewed changes

jtulach mentioned this pull request Aug 23, 2025

Honor the JAVA_HOME environment variable in nbexec script #8725

Merged

Prepand (not append) the directory of netbeans launcher

914565a

jtulach mentioned this pull request Aug 30, 2025

Propagate NETBEANS_USERDIR environment variable apache/netbeans-native-launchers#12

Closed

neilcsmith-net requested review from matthiasblaesing and mbien August 30, 2025 09:59

Open file from embedded terminal, easily! #8756

Are you sure you want to change the base?

Open file from embedded terminal, easily! #8756

Conversation

jtulach commented Aug 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

neilcsmith-net Aug 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

jtulach left a comment

Choose a reason for hiding this comment

Uh oh!

neilcsmith-net left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

jtulach commented Aug 30, 2025

Uh oh!

neilcsmith-net commented Aug 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mbien commented Aug 31, 2025

Uh oh!

neilcsmith-net commented Sep 1, 2025

Uh oh!

Uh oh!

jtulach commented Aug 23, 2025 •

edited

Loading

neilcsmith-net Aug 30, 2025 •

edited

Loading

neilcsmith-net commented Aug 30, 2025 •

edited

Loading