Tinderbox can pass commands to, and receive output from, the OS Command Line using the action operator runCommand(). This enables access not only to simple Unix tools like sed or ls, but to more complex tools like pandoc or programming languages like python. Data can be passed to extrenal tools or scripts and the evaluated data returned and passed to a Tinderbox attribute:
$Text = runCommand("ls -a"); $MyNumber = runCommand(vCmd, vArgs);
But what happens when the return value is missing or incomplete. Some notes follow on testing and debugging runCommand().
Testing output from Tinderbox
A useful check to make is that what is received by the Command Line is as intended. A first check is to run the expected output on the command Line in Terminal. Assuming that works, the next check is to confirm the output from action code is as expected/intended.
In the first example above, the output is a simple literal string,"ls -a", so can be seen and checked in situ in action code. In the second example, the output sent by runCommand() is created by two variables. To test the actual output, remove the enclosing run command() and pass the output—in the same originating context—to a String attribute or a note $Text for inspection:
$MyString = vCmd+", "+vArgs);
Note the inclusion of the joining comma+space, as the intent is to see exactly what is emitted by runCommand(). If the command involves setting/completing quotes, it can be useful to add enclosing (non-quote!) characters so it is clear exactly where the output starts and ends and that enclosing quotes aren't stripped when passed to the target attribute (as is normally expected behaviour. Thus:
$MyString = "#"+vCmd+", "+vArgs)+"#";
This the first test might export:
red", "blue but the second gives:
#"red", "blue"# It is difficult to generalise further, but the general point is to ensure the Command Line receives a command that is known to work
Testing returned output to Tinderbox
Here the reverse applies. Test in Terminal that the command sent generates a reply and the output is as expected. This can be done writing to a text file or direct to the Terminal.
Assuming the returned output appears correct outside Tinderbox, reverse the test above, passing the returned data to a String attribute or $Text. Bear in minds the point above about checking for possible missing enclosing quotes.
Incomplete Returns
If the returned data is complete at the Command Line and incomplete in Tinderbox look for possible issues in the data that may cause it to be misread in Tinderbox (e.g. unbalanced quotes, poorly formatted CSV data, etc.). Another possibility is slow/intermittent return.
Hangs and waits
The issue may be that the target process is slow to return data. There is no documented timeout but an assumption of c 30 seconds is sensible. If the target process has not completed within that time, runCommand() will stop waiting and the action will complete. Bear in mind the original concept of runCommand() was to call small/fast Command Line utilities, not as a call-and-wait process.
If a delay is expected in completion, use two calls, one that writes the data to a text file and a second action, to be run later, to read from that file. Tinderbox has no 'wait' process: it is up to the user to initiate the actions.
See also—notes linking to here: