Strange behaviour with #include with script ran from command line

[Jan32348180r79v]

I have a script that uses external JS libraries which I call by the #include directive; there are four of them, an example:

#include "D:/absolute/path/to/lib/papaparse.js"

Ultimately, I need to run the script from the command line; this I do with this command:

"C:\Program Files (x86)\Adobe\Adobe ExtendScript Toolkit CC\ExtendScript Toolkit.exe" -run "D:\absolute\path\myscript.jsx"

The problem is that the script does not run in its entirety and it stops just when a function from the external script is called. How do I know? I have the script to write logs to text files at certain points during its run.

When I run the script from the Extend Script ToolKit (ESTK)directly, it runs OK (ie. the functions from the external scripts are used without any issues). 

Why is there a problem when run from the command line and can it be resolved while still keeping external scripts linked to the main script? (I tried to copy all the code of the external scripts to the main script but it leads to some new problems that would take quite some time to resolve so I am trying to avoid this way if possible.)

Also, when trying to find out where the problem is I met with this behaviour for various forms of paths to the external scripts:

(1) paths to the external files relative (eg. /lib/papaparse.js) 

– runs OK from the ESTK

– from the command line, it only starts indesign but does not run further

(2) paths to the external files absolute (eg. D:/absolute/path/to/lib/papaparse.js) 

– runs OK from the ESTK

– from the command line, it runs but there are issues with loading the external files

Thanks for any advice.

[Jan32348180r79v]

(This is an addition to the original post)

I copied all the code of the external libraries to the main script (the problems I mentioned before could be resolved just by placing the code at the beginning of the file). When run from ESTK, it runs fully. When run from the command line, it stops at the same point as it does when the libraries are placed externally and linked with absolute paths. Strange.

[m1b]

Interesting. Are you able to work out which line is causing the stopping?

[Jan32348180r79v]

Yes, I am. It is a deduction from strategically placing a function that logs the run of the script. It stops just when it is calling the Papaparse library for the first time. 

[vnh68]

Unfortunately, this inconvenience has been going on for a long time. Script libraries cannot be linked by their full path. This will work if the path is relative to your script. Create a separate folder in the Scripts folder and carefully use ../../ to move the paths from your script to the desired location.

You can also try to make a startup script that creates a menu with the necessary scripts and launches them not from the general pile on the script panel, but from a separate folder. But at the same time, all scripts (if it is not a UXP plugin) must be located in the Scripts folder.

[Jan32348180r79v]

Hi, thank you for the reply. To be honest, I don't think I quite understand all of it 🙂

"Script libraries cannot be linked by their full path." – well, the script runs ok when the paths are absolute (and executed not from the command line).

"This will work if the path is relative to your script." – This is not quite clear to me. Can you give an example? My paths are like this:

#include "C:/Users/cgautomation/Documents/Adobe Scripts/lib/es5array.js";
#include "C:/Users/cgautomation/Documents/Adobe Scripts/lib/papaparse.js";
#include "C:/Users/cgautomation/Documents/Adobe Scripts/lib/pomocne_funkce.js";
#include "C:/Users/cgautomation/Documents/Adobe Scripts/lib/json2.js";

The script itself is here: C:/Users/cgautomation/Documents/Adobe Scripts/myscript.jsx

The scripts need to be int his folder because it is the safe location (from the OS point of view) and cannot be executed (to my knowledge) from other locations.

[Dirk Becker]

Is there any exception? e.g. wrap that call with try - catch and log the properties of the exception including the line number.

[Jan32348180r79v]

Hi Dirk, thank you for the reply. Yes, I do have it wrapped in the try-catch from the beginning. For some reason, it just stops at one point and does not go to the catch section at all so I am not able to get anything more specific. The line number I can deduce quite precisely because I placed my logging functions to the critical places by experimenting. The script enters the try section where the first line is the logging function that writes the log to a text file and then no other logs are created. So the very next line (var _resultingObject = Papa.parse(_textData, { delimiter: ";" });) must be the problem.

[Dirk Becker]

Output your $.includePath during execution

https://extendscript.docsforadobe.dev/extendscript-tools-features/dollar-object.html#includepath

There is also a matching #includePath directive.

As I mostly work on Macs, I don't know whether #include accepts other path formats, but I'd at least try URI.

Also output your Folder.current, and $.fileName .

If #include fails, maybe $.evalFile() is an alternative?

If your particular use of the ESTK is about jsxbin, have a look at the matching vscode extension.

There is a file exportToJSXBin.js, to be run by node.js, within public-scripts.

[Jan32348180r79v]

I have already tried $.evalFile(), no change. #includePath I will try.

Folder.current returns this: ~/Documents

$.inlcudePath returns this: C:\Program Files\Adobe\Adobe InDesign 2023\Scripts;C:\Program Files\Adobe\Adobe InDesign 2023\Scripts\Community;C:\Program Files\Scripts;C:\Users\jziebiker\AppData\Roaming\Adobe\InDesign\Version 18.0\cs_CZ\Scripts

$.fileName returns this: indesign-18.064:bridgetalk

(it was all tested on my local machine but the behaviour was always similar on the system where the script is eventually supposed to run)

Can you tell something from this?

No need for the jsxbin; in fact, the script is part of a larger automation environment and is actually created dynamically based on some input parameters, so it needs to be a plain text file. I have actually already solved my needs differently using Node.js (the parts of the InDesign script that did not run actually do nothing indesign-specific so I can move those tasks to Node or other tool). Still, I am curious about the #inlcude problem with the external libraries.

[Dirk Becker]

We're looking for differences between (ESTK run from commandline) and (run from ESTK UI).

Above output indicates that you're running on InDesign instead of ESTK. Make sure your target host dropdown is pointing to ESTK - if you still think you need ESTK at all, I'm not yet convinced.

Otherwise - if that particular test run works - your equivalent commandline would tell InDesign to run the jsx directly, and ESTK is out of the game.

[Jan32348180r79v]

Hi, thanks again. Well, this is a new distinction for me. What I need is to run scripts in InDesign via the command line. The only way I knew how to do this was to use the command 

"C:\Program Files (x86)\Adobe\Adobe ExtendScript Toolkit CC\ExtendScript Toolkit.exe" -run "D:\absolute\path\myscript.jsx"

This actually does not start the ESTK interface/application (and that is because there is the -run flag) and does what I need, ie. starts in design and runs the script in it. So I would say that I do not need ESTK app and ESTK is not my target, InDesign is. Is that thought process correct? Does it change anything in terms of the original question?

[Dirk Becker]

I'd try along the styks answer here:

https://stackoverflow.com/questions/37320580/how-to-execute-an-indesign-extendscript-from-command-li...

It uses powershell to create an InDesign COM object, then invokes app.DoScript(). The first parameter is the script file, second is the ScriptLanguage value. The unused (there) additional parameters would be an array of arguments, UndoModes enum and undo-name of the sequence. Don't ask me how to make up that array of arguments in Powershell. An alternative to Powershell would be VBScript, or if you're coming from other managed code (C#) those all understand COM. In that case, watch out for discussions about InDesign TLB.

[Dirk Becker]

As you still have ESTK around, you could even have it connected to your InDesign, make sure you enable breaks on caught exceptions (somewhere in the menu), set a couple of breakpoints and use it as Debugger on the troubled code.