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 |
- [Bug-apl] #!apl Hudson Flavio Meneses Lacerda
- Re: [Bug-apl] #!apl Juergen Sauermann
- Re: [Bug-apl] #!apl Hudson Flavio Meneses Lacerda
- Re: [Bug-apl] #!apl Juergen Sauermann
- Re: [Bug-apl] #!apl Hudson Flavio Meneses Lacerda
- Re: [Bug-apl] #!apl Juergen Sauermann
- Re: [Bug-apl] #!ap... Hudson Flavio Meneses Lacerda
- Re: [Bug-apl] ... Kacper Gutowski
- Re: [Bug-apl] ... Juergen Sauermann
- Re: [Bug-apl] #!ap... Hudson Flavio Meneses Lacerda
- Re: [Bug-apl] ... Juergen Sauermann
- Re: [Bug-apl] #!apl enztec
- Re: [Bug-apl] #!apl enztec