How to handle a big text as the input of a Ruby script? (I'm getting Couldn't posix_spawn: error 7)

[MatiasFernandez]

Hey folks, I'm having trouble with a workflow I'm trying to build. I isolated the culprit but don't know how to fix it.

 

I'm trying to build a workflow using a Ruby script that grabs a list of "text lines" (a big string with 'new line' characters separating it into multiple lines) and processes them into something different, such as joining the lines by a character.

 

The trigger for the workflow is a universal action, and I managed to reproduce the issue with an empty Script Filter using `ruby` as the selected language. It happens when I use "with input as {query}" and also with "with input as argv".

 

When I select a big list of UUIDs (approximately 80k lines) and trigger the universal action I get an error saying: "Couldn't posix_spawn: error 7"

 

In the debugger I'm seeing: "[18:59:07.177] ERROR: My Workflow[Run Script] Task '/usr/bin/ruby' failed with reason 'Couldn't posix_spawn: error 7'"

 

The Ruby script is the default one, it only contains this: 

 

query = "{query}"

print query

 

My understanding is that the input I'm selecting is too big to pass it to my script. I understand that when using argv, because it would result in a huge command with tons of args. But it's less clear to me why it happens when using "{query}".

 

Is there a way I can capture this content into my workflow without crashing this way? I would love to be able to manage big lists of UUIDs like this one.

 

Apart from that, it could be useful if Alfred protects itself against too big of a payload with a more meaningful error. But if that doesn't happen, is there a way I can code my workflow to render a better error for the user if tries to process a string that is too big?

 

Versions of software I'm using:

MacOS: Sonoma 14.7 (23H124)

Alfred: 5.5.1 [2273]

 

Thanks!

[FireFingers21]

@MatiasFernandez Welcome to the forum!

 

What's the behaviour if you isolate the script from Alfred? I often like to test and debug these things with a dedicated script file that I run with the Terminal first. That way I'm not troubleshooting my code and Alfred at the same time. At that point you may also find it easier to run your code as an External Script.

Edited December 5, 2024 by FireFingers21

[FireFingers21]

6 hours ago, MatiasFernandez said:

it could be useful if Alfred protects itself against too big of a payload with a more meaningful error

 

There's also not too much special about the Run Script Action, for the most part it just runs your code. Since code could be anything, any conditional logic or specific error handling is on the programmer to implement. Of course any help you need with that is extremely hard to give without knowing what the Workflow and its code look like.

[MatiasFernandez]

Hi @FireFingers21, thanks for your reply. 

 

I ran some more tests, and I think the issue is related to how Alfred passes the {query} to the script. I guess it must still be using argv or something similar, hence getting into a maximum size that causes the error.

 

Let me upload some files to reproduce the issue. The workflow includes a script that receives {query} into a Ruby string and won't do anything with it. 

 

You can reproduce the issue by opening the text file, selecting everything, and trying to run the universal action included in the workflow. 

 

Using an external script doesn't seem to be an option because Alfred uses argv to pass the query into the external script, and then I would run into the same limitation.

 

Here is the workflow and the text file to reproduce the problem: https://www.dropbox.com/scl/fo/yat3l66fvkeb0z07hvi4m/AIPTmeoTwme4wUpOdzAJe2M?rlkey=33zf5x66gfh9i2v1ff5kzfii2&dl=0

 

You can also see the workflow is valid if you select all lines but one, and you run the universal action. It works without crashing.

 

Thanks

Edited December 5, 2024 by MatiasFernandez

[vitor]

This is a kernel limitation, not an Alfred limitation. You can learn more about it by searching for “argument list too long” or similar, it’s not even exclusive to macOS. As @FireFingers21 noted, this is something you can verify yourself by simply trying to run the same thing in a terminal, and it’s not something Alfred itself should try to work around in the sense that it would change the execution of the program and possibly cause it to behave differently.

 

The workaround for your case is simple: add a Write Text File Output right after the Universal Action to save the contents to a file, whose path will be passed to the next object. At which point you tell your script to read the file contents.

[MatiasFernandez]

@vitor does that mean that both methods of passing arguments to a script (using query or using argv) are passing the input as the script arguments? I thought that using query and interpolating it within the script would mean Alfred interpolates the query within the script text before running it, hence avoiding the max arg limitation. 

 

Writing to a file looks good. But I'm wondering if there's a way I can conditionally follow that path according to the argument size. To avoid doing it for smaller payloads too (in case there's a perceptible performance difference. I need to try and see what happens) 

 

The recommendation I gave for Alfred is not to circumvent this limitation necessarily, but to implement a mechanism to detect when the payload is too big and fail gracefully so users could get a clearer feedback. For example, something like "input is too big to be handled by the workflow".

 

If it's possible to implement that validation within my workflow I can also do it. For now given this is only used by me, it's ok to crash because now I understand what's happening, but I have the intention to prepare the workflow for public release so I wanted to understand how to give feedback about the limits of the workflow if the user is picking a payload that is too big. 

 

Thanks for you answer!