Writing to stdout and/or process return value

[harsman]

Is there any way to write to stdout or stderr in Dyalog 12.1 for Unix without using []NA? Alternatively, can you set the return value from the Dyalog process somehow to indicate success (retval 0) or failure?

We can do various workarounds (create a file with a return code and read that in a script surrounding the invocation of Dyalog) but to not be able to do it the direct way is kind of insane to be honest.

If we need to use []NA to write to stdout, can we make sure we do not trample on the fd's opened by Dyalog somehow? I know from experience that Dyalog can use fd's normally reserved for stdout/stderr for other things.

[AndyS|Dyalog]

[Updated 2012-04-27 to add more detail about the exit codes]
[Updated 2015-08-12 to add details of exit codes 4-8]
[Updated 2016-06-21 to remove comment about codes 4-8]
[Updated 2017-07-17 to point out that RIDE libraries no longer exist in 16.0]
[Updated 2018-11-12 to add comment detail about codes 9-11]
Hello Joakim

Since the very early days of Dyalog APL, we have split output across stdout and stderr.
Anything assigned to ⎕ or returned to the session is written on stream 1 (stdout).
Anything assigned to ⍞ or anything written by the session is written on stream 2 (stderr).

So for example the banner is written to stderr, and if you type

      1+1

then the 1+1 is written to stderr, but the 2 is written to stdout.

[As as aside, from 12.1 onwards you can redirect the "status window" output elsewhere: set APLSTATUSFD to the stream that you want to use, and then when you start APL, redirect that stream to a suitable location. So

      export APLSTATUSFD=9
      mapl 9>status.out

will result in all the status window output being redirected to status.out]

Dyalog has a number of specific exit codes, but you can also follow ⎕off with an integer; this integer is used as the return code to APL. ⎕off is a niladic function; it is the parser which identifies this special "syntax". As a result of this, some expressions which you might expect to work won't.

We use this facility in the overnight QAs; I have standardised on 10 for success and 11 for failure of the QA code - then I can distinguish between a clean exit from Dyalog APL and a clean exit from my application (in this case, the QAs).

The standard exit codes from Dyalog APL are:

      0: Successful exit from ⎕off, )off, )CONTINUE or graphical exit from GUI
      1: APL failed to start (for example, lack of memory, bad translate table etc, invalid value of environment variable)
      2: APL received a SIGHUP or SIGTERM (these can be caught in the interpreter)
      3: APL syserrored
      4: Runtime violation (eg attempting to read from the session)
      5: Unable to load RIDE (in 16.0 Conga) libraries (14.1.25383 onwards)
      6: RIDE_INIT is ill-defined, or hostname/port number is not valid or available (14.1.25383 onwards)
      7: <reserved>
      8: Windows has rejected APL's request to create a session window (used to be syserror 126)
      9: The interpreter has encountered a Windows-related problem on startup and cannot continue (MS Windows only)
     10: CEF subprocess crash - something has gone unexpectedly wrong with either the HTMLRenderer or CEF subprocesses and cannot continue
     11: Cannot create c-stack (macOS only)

Under UNIX exit codes greater than 128 indicates (128+signal number) of the untrapped signal which caused the process to terminate.

In 16.0 onwards the RIDE support is no longer supplied as separate libraries, but rather the functionalituy is included in the Conga libraries.

[harsman]

Wow, that's great. I remember this not working at all in v10.0 for AIX, but maybe that was just the special build we had. Good to know it's been fixed!

[AndyS|Dyalog]

I've updated my first post so that everything is together.

For completeness' sake I should also point out that you can use ⎕arbout, but you would need to be sure that you have opened the relevent stream before you start APL (by adding something like mapl 17>myfile) and only wrote to stream 17. Writing to other file descriptors, especially those associated with open files, is likely to have most undesirable consequences !

[harsman]

The standard way to start Dyalog on AIX is the mapl script. For the runtime version it contains this line:

Code: Select all

case $RUNTIME in
True)
        $DYALOG/dyalog.rt.5390 $OPTS $WSID 0<&- 1>&- 2>&- &

Since Dyalog is run asynchronously here, it's not possible to get the return value. So I created a copy of the script, lets call it mapl_sync and removed all the stream closing and the &:

Code: Select all

case $RUNTIME in
True)
        $DYALOG/dyalog.rt.5390 $OPTS $WSID

Now I can set the return value by giving an argument to ⎕OFF, but I can't get any output to neither stdout nor stderr. I tried assigning to ⎕, ⍞ and just returning stuff to the session. No dice.

Is there any special incantation I need to use to get output to stderr or stdout?

As an aside, wouldn't it be better if the standard script redirected to /dev/null instead of closing stdin, stdout and stderr?

[Geoff|Dyalog]

Runtime versions simply throw away attempts to write to the session. Originally the APL would terminate in this case but it was thought unfriendly and output is discarded.

In development versions output from default display and output via ⎕← goes to stdout (filedescriptor 1). Display of error messages and output via ⍞← goes to stderr (filedescriptor 2).

Messages intended for what would be the status window on a Windows platform are sent to file descriptor 2. Indeed even on a development platform they are displayed in your terminal but they are not part of the session so a screen redraw (Ctrl + L on most input translate tables) causes them to disappear.

[AndyS|Dyalog]

.. and if you do not close streams, APL will want to have an appropriate APLK/APLT file defined and available ..

[AndyS|Dyalog]

In 14.1.25383 on onwards we have added two more exit codes which indicate problems with starting RIDE; I have also taken the opportunity to update the list to include all exit codes which the interpreter currently uses.

Note that we have also just fixed an issue which meant that APL terminated with an exit code of 0 even if a critical configuration paramenter was invalid.

[AndyS|Dyalog]

I've updated the list of exit codes to include 9, 10 and 11.