I am trying to learn APL (both APL in general and Dyalog APL, which seems to be actively under development and in use here in Stockholm).
When doing so, I have observed, in my Ubuntu Linux environment, that dyalog (in fact a file called mapl, which is reached through a symbolic link named /usr/bin/dyalog) seems to be behave differently when having stdin associated with a pipe or open disk file instead of the terminal driver.
It seems that the interpreter no longer understands ]DISPLAY when I replace my terminal driver with a pipe as standard input.
Here the ]DISPLAY command/function seems to work :
Command: dyalog without arguments or stdin redirection :
Dyalog APL/S-64 Version 16.0.30320
Unicode Edition
Mon Aug 14 19:27:14 2017
]DISPLAY 42
42
Here, the interpreter seems to be confused about ]DISPLAY :
root@lenovo201707:/home/u/20170814# ( echo "]DISPLAY 42" ; echo ")off" ) | dyalog
Dyalog APL/S-64 Version 16.0.30320 Unicode
For i86_64
Created: Jul 7 2017 at 02:48:48
Copyright (c) Dyalog Limited 1982-2017
]DISPLAY 42
VALUE ERROR
root@lenovo201707:/home/u/20170814#
Is there a simple way to not lose the ]DISPLAY function when loading and executing my APL code from an existing UTF-8 encoded file ?
Best regards ! Hans Davidsson
Updated answer: the following should solve your request:
( echo "]DISPLAY 42" ; echo ")off" ) | /opt/mdyalog/16.0/64/unicode/mapl salt
The only detail that has changed is that we're now loading the salt-workspace before attempting to execute the UCMD. SALT will (through its ⎕LX) set up the environment so that it can handle UCMDs.
My initial reply: I'm a Windows-User and must admit that I never worked with Linux Pipes, so I can't help with the general mechanism.
But I have an answer for the specific question re. ]DISPLAY
: you may call any UCMD under program control using ⎕se.UCMD'{ucmd & args}'
, so for example: ⎕se.UCMD'DISPLAY ⍳3 3'
BTW, I personally call ⎕se.Dyalog.Utils.disp MyVar
which avoids the UCMD-Mechanism and is even easier to use when calling from a fn.