How about checking if argv[0] is "aplscript" and then run it as if --script had been given?
That would allow you to symlink apl to aplscript and provide both behaviours. Regards, Elias On 5 Jun 2016 17:53, "Juergen Sauermann" <juergen.sauerm...@t-online.de> wrote: > Hi Xiao-Yong, > > you can already run apl as proposed. The only difference is that --script > is not automatically implied. > > But setting --script automatically would make the use of GNU APL > incompatible with the needs of > other users (including myself). > > I normally write my APL programs in a separate text editor and then run > the text file (without --script) with: > > * apl textfile* > > /// Jürgen > > > On 06/02/2016 03:58 AM, Xiao-Yong Jin wrote: > > 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 <juergen.sauerm...@t-online.de> > <juergen.sauerm...@t-online.de> 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: > eedjsa@server66:~/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: > eedjsa@server66:~/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 > > > > > >
