This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
We are creating an interactive command-line application using NetBeans platform. We've implemented an org.netbeans.spi.sendopts.OptionProcessor, which uses Env.getInputStream() and Env.getOutputStream() in its process() method to get input from user and produce output. At the end of process() method the System.exit() is called. The problem with this approach is that input stream is always empty, even if user types something, because the default NB launcher script platform/lib/nbexec starts Java in background effectively detaching it from stdin: 512: eval ${_NB_PROFILE_CMD} "\"${jdkhome}/bin/java\"" -Djdk.home="\"${jdkhome}\"" -classpath "\"$cp\"" \ 513: "$jargs" org.netbeans.Main "$args" '&' Removing '&' from the above line solves the problem. Is it possible to modify the nbexec script to leave Java process in foreground? Or maybe there is a better approach to creating command-line applications on NetBeans platform?
core-main#a8cb534ee221
Thank you!
The current fix is in contract with bug 73162. I will have to revert it. Jesse wrote: http://hg.netbeans.org/main-silver?cmd=changeset;node=a8cb534ee221 Please revert this change, as it will regress #73162 which is rather important for Platform development on Unix, more so (IMHO) than supporting stdin. There might be some way of passing file descriptor 0 to a spawned subprocess, I am not sure. For #73162 to be fixed it is necessary to either trap EXIT as in my fix, or exec the subprocess (which would prevent the platform from restarting after updates).
Use of the NB platform for CLI apps has never been a supported use case so I would consider this an RFE. I can't imagine how Env.inputStream could ever have worked. Anyway I would not recommend using the NB launcher and module system if you are writing a CLI app. sendopts is designed to provide simple remote commands for a running app, not to be a complete CLI; module system infrastructure will make startup much slower; and you lose control over logging and other details of stdio (e.g. System.console). Better to simply write a plain old main class and put any NB modules you need as libraries in its classpath.
It used to work and I rely on that in dvbcentral.sf.net a bit too, the change in nbexec is in fact regression.
Since 6.0?
DVBCentral used to be based on 5.0 for a long time. Just recently I switched to 6.8. New fix in core-main#153ebea827d5
Fix looks right. It might not work if the app in fact restarts, but I think this is a corner case.