Hi,
your example looks like you are not waiting until ⎕SVO has
succeeded.
You assign to a shared variable before it was entered into the
shared variable
database.
Have a look at testcases/AP100.tc for how to use it
(hint: check the coupling level
with monafic ⎕SVO or with command ]SVARS).
There is no principal difference between scripts and immediate
execution, except that
scripts provide a much faster input than humans. That's why your
problem below does
not occur in immediate execution.
BTW: ⎕FIO[24] aka. popen() and ⎕FIO[25] aka. pclose()
are much easier to use
than 100 ⎕SVO (aka. AP100)
/// Jürgen
On 08/24/2018 02:59 AM, Hudson Flavio
Meneses Lacerda wrote:
Hi.
Thank all you for the inputs. My remarks about #!apl go below, after
reporting a problem.
PS.: Jürgen: can you use AP100 from scripts? Example:
#!/usr/local/bin/apl --SV -q -f
100⎕SVO'SO'
SO ← 'date'
)off
On my machine, usually I get this:
«««
Svar_record_P() failed at ../Svar_DB.cc:324
Could not find svar for key 65601537 at APmain.cc:314
»»»
Apparently, 'date' is not executed; rarely, it succeeds.
Some points about executable scripts, after tests:
a)
#!/bin/bash
⍝(){ :;};exec apl -s "$0" -- "$@"
'script body'
)off
Concise and elegant, but it does not work in environments with $CHARSET
incompatible with Unicode (trying to use '⍝' as function name).
b)
#!/bin/bash
':' ⎕EA''⍝;exec apl -s "$0" -- "$@"
'script body'
)off
So far, my preferred approach. Bash takes '⍝' just as argument for
':' (the null command), thus the script can work in any $CHARSET
environment (because Unicode is interpreted only by GNU APL, not by
Bash).
c) symbolic links
ln -s `which apl` ~/bin/aplscript
It does not work. GNU APL cannot find components like APxxx.
d) aplscript as script
Setup:
cat>~/bin/aplscript<<END
#!/bin/bash
apl -s "\$0" "\$@"
END
chmod +744 ~/bin/aplscript
APL script:
#!/usr/bin/env aplscript
'script body'
)off
It may work, but requires the additional setup effort, not just a
simple, standard, GNU APL install.
e)
#!apl
'script body'
)off
It only works when called from apl path; that path must be in $PATH.
If "apl" is a copy or symlink inside `pwd`,
GNU APL may have problems finding libraries.
Moreover, current directory "./" must be in $PATH
(e.g. trailing ":." or trailing ":").
Summing up: so far, I find this (below) is the best approach, because
it is simple and functional (I presume /bin/bash is popular enough for
compatibility between environments; anyway, the first line may contain
just "#!").
#!/bin/bash
':' ⎕EA''⍝;exec apl -s "$0" -- "$@"
'script body'
)off
Thanks.
Hudson
|