Limits to runCommand()?

Hi all, just a few questions about runCommand():

  • Is there a limit to how much text can be returned?
  • Will runCommand() time out and when?
  • Has anyone experienced trouble with getting a large amount of text from runCommand()?

I have a number of stamps that grab text from my notes, format it as a command, and evoke it using runCommand(). The command launches a Python script, which returns a block of text.

Sometimes this works perfectly, but other times the returned text is cut off (usually at about 500 words or 90-99 lines), and other times I get no response (maybe this is a timeout?).

Whenever this happens its easy enough to run the exact same command in the terminal, which gets the response I want without errors. But it would be nice to not have to perform that extra step!

Any ideas?

There’s a timeout — I think it’s 30sec.

I don’t think there’s a length limit. How much text are we transferring? Dozens of lines? Megabytes? When you get a partial result, how much do you receive? I checked the code, and while there might be issues at 4K and 64K, it ought to be fine for big data.

I’d be happy to take a closer look at the problem, if you like. Or, if you just want to Get It Done, consider starting the script from runCommand and having the script write to a disk file, which you can poll after a reasonable delay.

Thanks Mark. The text gets cut off at about 500 words, or 90-99 lines. It’s a lot of formatted JSON, so it has many line breaks. I can adjust the script settings to limit the number of records transferred, and I get no cutoff until I’m over those limits. Exact numbers vary from one case to the next, but always in that range.

I had considered sending the data to a file. Any thoughts on Tinderbox commands to pull the data from the text file? Or were you thinking about pulling it in manually?

I’d be glad to work with you on this, but it would be hard to reproduce the issue since some of this is happening outside of Tinderbox. Open to suggestions though!

Here’s one idea.

You have a script that’s sending some json to Tinderbox via stdout. Something’s getting fouled up. Let’s identify the culprit.

  1. From terminal, running your script as you would do runCommand, sending the output to a file: > testData,json

  2. Now, write another script that simply copies that file to stdout. Or just pass cat testData.json to runCommand!

I bet this is going to fail. Now, you can send me the sample file and a Tinderbox document with the single note that invokes the runCommand action, and I’ll be able to figure out what’s wrong.

OR, this is going to succeed, and we know it’s more complicated. (Maybe the data source is timing out?). But I think that’s less likely.

Huh. It succeeded. So I guess it’s more complicated! Sorry!

  1. Made a stamp that evoked the Python script but instead of $Text = runCommand(myCommand), I followed your suggestion and sent the results to a file.
  2. Made another stamp that imported the file to $Text, following your suggestion.
  3. Ran the original script on the same note just to be sure. Ran a stopwatch and found it took 10 seconds to return a response.

Numbers 1+2 gave me a complete reply, all the lines of the JSON file.
Number 3 gave me the first 80 lines of the expected response, then cut off in the middle of a word.

Knowing that this is more complicated, I’d be glad to settle for a workaround. Will I need two stamps, like I have now, or is there a way to pause the Tinderbox stamp in a while loop, forcing it to wait for the file to be written?

Two stamps is possible. Or you could do a stamp and a rule:


  • delete the file if it already exists
  • run the script to create the file

If you are checked, do nothing.
Grab the text from the file.
Parse it and act on it.
Set $Checked to true.

But there are other ways, and two stamps will do fine.

I’ve added an article to aTbRef’s section on debugging action code see here. It is cross-linked to the article on runCommand().

N.B. The new article is listed in an updated site map page, but not yet in the uplaoded source ZIP file or in the fuzzy search.

Thanks Mark, I really appreciate the help. Doing this through a rule is pretty slick. :+1: