ubuntu - Redirection of standard input seems to change behaviour of Dyalog APL program (when calling mapl using symbolic link named dyalog) -
i trying learn apl (both apl in general , dyalog apl, seems actively under development , in use here in stockholm).
when doing so, have observed, in ubuntu linux environment, dyalog (in fact file called mapl, reached through symbolic link named /usr/bin/dyalog) seems behave differently when having stdin associated pipe or open disk file instead of terminal driver.
it seems interpreter no longer understands ]display when replace terminal driver pipe standard input.
here ]display command/function seems 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, interpreter seems confused ]display :
root@lenovo201707:/home/u/20170814# ( echo "]display 42" ; echo ")off" ) | dyalog dyalog apl/s-64 version 16.0.30320 unicode i86_64 created: jul 7 2017 @ 02:48:48 copyright (c) dyalog limited 1982-2017 ]display 42 value error root@lenovo201707:/home/u/20170814# is there simple way not lose ]display function when loading , executing apl code existing utf-8 encoded file ?
best regards ! hans davidsson
updated answer: following should solve request:
( echo "]display 42" ; echo ")off" ) | /opt/mdyalog/16.0/64/unicode/mapl salt the detail has changed we're loading salt-workspace before attempting execute ucmd. salt (through ⎕lx) set environment can handle ucmds.
my initial reply: i'm windows-user , must admit never worked linux pipes, can't general mechanism.
but have answer specific question re. ]display: may call ucmd under program control using ⎕se.ucmd'{ucmd & args}', example: ⎕se.ucmd'display ⍳3 3'
btw, call ⎕se.dyalog.utils.disp myvar avoids ucmd-mechanism , easier use when calling fn.
Comments
Post a Comment