Scripting in V18

[paulmansour]

So in v18 we have the new Load parameter. However, it does not appear that I can load and execute a text file (let's call it a script file) like:

      ]box on
      ]display ⊂⍳10

Am I missing something? I can do this with no footprint by piping in standard input from another APL session using .NET (and with the new multi-line input feature its awesome, I can execute anything!). Shouldn't I be able to do this from a text file?

[paulmansour]

I was just testing with a .txt file, but I assume the extension is immaterial. The load parameter currently recognizes .dws, .aplf, .aplc and .apln. Is there a convention yet for what a script file's extension should be ? .apl seems appropriate - its general and the fourth character then gets specific.

[Adam|Dyalog]

A problem with simply piping in is that any ⎕ or ⍞ will take the next line as its input.

Instead, call

Code: Select all

dyalog DYALOG_LINEEDITOR_MODE=1 -script filename

[Morten|Dyalog]

Resolving the issues related to redirected input and output is an important goal of Dyalog v19.0.

[paulmansour]

I'm not promoting piping nor do I have a problem with it. I asked how to execute a script.

The V18 documentation states this:

Loading a Script
Instead of starting a workspace, APL can be instructed to load a program from a
script file. This is achieved using the Load and LX parameters which may be
specified on the command line or via a Configuration file.
Examples:
"c:\program files\…\dyalog.exe" myapp maxws=64000
"c:\program files\…\dyalog.exe" session_file=special.dse
"c:\program files\…\dyalog.exe -x myapp aplt=mytrans.dot
default_io=0 myparam=42"
"c:\program files\…\dyalog.exe SALT\CommandFolder=c:\salt cellar"
"c:\program files\…\dyalog.exe SALT_CommandFolder=c:\salt cellar"

I cannot find any mention of -script. It does not appear to be documented as either a command line option or command line parameter. Is it documented somewhere else? Is it experimental or can I rely on it?

I tried it and it appears to work. I suppose with enough experimentation I can figure out how errors are handled and if any stdout or stderr or return code is provided.

[Morten|Dyalog]

-script is not documented because it is considered to be work in progress, to be completed properly and documented in v19.0. If you can make do with LX and/our LOAD or configuration files in v18.0, that is what I would recommend. You may be able to get things to work with -script but we cannot support it or guarantee that it won't change in v19.0.

The examples in that documentation need to be updated to show some more up-to-date examples, we'll get that done too.

[paulmansour]

That's fine. I can probably make do with LOAD and LX, and I'll treat -script as experimental.

[paulmansour]

Is there any reason that -script should fail if using the runtime interpreter and something is done in the session? I understand historically why it does now, but in V19, is there any reason that it should fail in using runtime?

Edit: and same question for piping in stdin.

[paulmansour]

Maybe the real question is "are most if not all of the runtime restrictions not really appropriate at this point"? That is, the point that a no-questions-asked free download of the full interpreter is available?