Hi Juergen,
Thanks for the script trick. The script in my previous email
works for all the cases when bash is in different places (your
bash script still requires /bin/bash which fails in *BSD, but
/usr/bin/env actually exists for all the systems I have). I
wanted to ask if it is OK for you to change the apl command line
handling such that it resembles python or julia, so running
apl script.apl
would be the same as given '--script'; while running it without
an explicit file argument makes it enter interactive mode just
like it does currently.
Best,
Xiao-Yong
On Jun 1, 2016, at 7:29 AM, Juergen Sauermann <address@hidden> wrote:
Hi Xiao-Yong,
there was a brief discussion on bug-apl earlier this year:
http://lists.gnu.org/archive/html/bug-apl/2016-02/msg00045.html
and my conclusion was that the env approach does not work for GNU APL.
The problem seems to be that in:
#! /usr/bin/env: apl --script
env searches for an executable named "apl --script" and does, of course,
not find it. This seems to be a consequence of env using execve() and friends (see
man execve) and I consider this to be a bug in env. All this happens before GNU APL
has even started,
A simple work-around is probably to put apl with the desired options (in particular --script)
into yet another script , say run_apl:
address@hidden:~/projects/juergen/apl-1.5/src$ cat run_apl
#! /bin/bash
# additional arguments
apl --script -- $0 << ENDCAT
'script arguments:' ⎕ARG
)OFF
ENDCAT
If you run that script, then you get:
address@hidden:~/projects/juergen/apl-1.5/src$ ./run_apl
script arguments: apl --script -- ./run_apl
which shows that the arguments given to apl (or to the workspace after --)
can be accessed. You can then open/parse run_apl with ⎕FIO functions.
/// Jürgen