progress runtime exit value 2 on linux

do you need a terminal entry defined ? If batch works (no terminal)

and terminal works (you have a terminal) then perhaps it may be the

problem.

my 2c worth of guessing

jmls wrote:
do you need a terminal entry defined ? If batch works (no terminal)
and terminal works (you have a terminal) then perhaps it may be the
problem.
my 2c worth of guessing 

Thanks Julian, guessing sometime works but was not the case here... I begin to think this might be one of the reasons for trashing the Linux version of OEA, no matter what I try (ProgressBuilder or Runtime) it seems not possible to start the AVM without using batch mode

I'll try to fill a case with TS to see if there is something that can be done, I hope they'll find a way to tell me how stupid I am and eventually get this to work

would you tell us why batch mode is no good ?

Also, how about redirecting standard input / output to /dev/nul ?

would you tell us why batch mode is no good ?

just  trying to get the run configuration implemented so I can actually run  code from my rudimentary home-made IDE, and would like to have messages  view as alert-boxes to be able to say "hello world"

Also, how about redirecting standard input / output to /dev/nul ?

redirection only works if batch mode is used, that at least it make sense I guess so won't try to fight it.

however, if everything fails I'll have to leave with redirecting the output to a console view and skip the alert-box

Hello,

What about running exec of xterm -e "pro"?

I hope this helps.

Try putting a terminal emulator in between. Something like xterm -e _progress ...

Try putting a terminal emulator in between. Something like xterm -e _progress ...

yeah,  that does it... guess I'll have to try with `exec` as well and then  find a way to figure it out which one to use if the plain _progress  executable does not start

incidentally, anyone knows how to hide the terminal window now that it gets opened?

Just to close this, I'll stick to batch mode for the project builder and only use xterm for run configuration... I'm sure there is a perfectly valid explanation on why we need to have the terminal console to run _progress in X environment and in the end this is what i want (kind of)... run in batch and don't see it for build/check syntax and pop-up when I want to run some code

Thanks guys.

The runtime requires the terminal because it needs some place to send its output that can support the terminal commands it needs to paint the pretty frames and browse widgets and stuff.  Batch mode explicitly tells the ABL to not send these, but in return you promise not to create window objects and stuff in your code.  It does other stuff such as not trying to popup message boxes (since it can't paint them).  stdout and stderror don't provide the right environment for painting widgets so if the runtime doesn't detect a proper terminal setup, it quits out unless you run in batch mode.

If you don't want the window you can wrap it in the 'screen' program and run it detached by default.  Just make sure you have a way to clean it up.

http://linux.die.net/man/1/screen

The TTY client can't popup a dialog in a separate window.  Its a console app, not a windowed app.

So what you propose is right,  do compile in a hidden batch session, and suppress all the output to the screen.  If you want to run code, kick off a separate instance that isn't batch and opens a console window.  This is what PDS does (except on windows you don't need the -b flag because of the hidden "default" window that gets created). 

FYI: You can still make PDS use the "project" AVM for running stuff like it used to prior to 10.1C, but this is a bad idea for several reasons related to memory such as statics, shared variables, and database connections.

mbaker wrote:
The runtime requires the terminal because it needs some place to send its output that can support the terminal commands it needs to paint the pretty frames and browse widgets and stuff.  Batch mode explicitly tells the ABL to not send these, but in return you promise not to create window objects and stuff in your code. 

Thanks Matthew, so it's like something in between engagement and marriage ... let's go for the batch mode and behave ourselves, no fancy widgets for me.

So what you propose is right,  do compile in a hidden batch session, and suppress all the output to the screen.  If you want to run code, kick off a separate instance that isn't batch and opens a console window.

Thanks, that makes sense... for batch mode I can get the output/error in a console, when running code a new gui/terminal session should work.

FYI: You can still make PDS use the "project" AVM for running stuff like it used to prior to 10.1C, but this is a bad idea for several reasons related to memory such as statics, shared variables, and database connections.

Indeed, separate process for run configuration it is then... interesting association of statics and shared variables

When I have to fool around with .Not UI PDS is a must so I have to start a Windows VM... most of the time I'm just happy to write code that have no UI so leaving my penguin alone does not make any sense.

mbaker wrote:
The runtime requires the terminal because it needs some place to send its output that can support the terminal commands it needs to paint the pretty frames and browse widgets and stuff.  Batch mode explicitly tells the ABL to not send these, but in return you promise not to create window objects and stuff in your code.  It does other stuff such as not trying to popup message boxes (since it can't paint them).  stdout and stderror don't provide the right environment for painting widgets so if the runtime doesn't detect a proper terminal setup, it quits out unless you run in batch mode.

Just  one thing that might also worth mentioning is that it matters how the  start-up program looks like... meaning if the start-up (-p argument)  program doesn't use any graphical output then the session can start in  batch-mode, running other programs from that point that does normally  require graphical output (because of view-as alert-box for instance)  might work

So, starting the runtime with a .p that does alert-boxes will fail if no  graphical output while is the start-up just starts listening on a  socket and later executes the same .p works - the alert-box option is  striped down however and the output is sent to standard output.

As you've said the runtime tries to convert those for the batch  environment, display and message view-as alert-box still works (stream  to stdout) but most probably things like browse widgets won't work...  think anything that requires user interaction does need a graphical  output.