Jump to content

Troubleshooting Split -> JSON Config -> Script


Recommended Posts

I am having an issue and would love it if someone could take a look. There's actually a really interesting quirk happening that almost makes me think this could be a bug. 

In summary: Using the contents of a Split Arg is not working as expected when fed into a script via JSON Config object.

 

I uploaded a copy of the workflow here: https://github.com/NeighNeighNeigh/Alfred_HotkeySystem/blob/main/Troubleshooting splits into scripts 01.alfredworkflow

 

and I've put a little screencast together to demonstrate the issue:

 

 

Link to comment

@Floating.Point The JSON Utility is caching the initial value of the split2 variable, as you discovered when modifying the workflow causing a reload. I don't ever use that object, so I don't know why it only lets you modify the "script" config once.

 

That said, you're probably looking for the eval command, which lets you execute arguments as a shell command. Try removing the Arg and Vars and JSON Utility objects and just go straight into the Run Script, then set the script within to eval $split2. Your test workflow should work as intended.

Link to comment

Ah thank you @FireFingers21 for both confirming my issue is actually real, and for providing a beautiful solution! I just tested now and it works flawlessly for ZSH. I also did a quick search for an equivalent in Python (which I'll need) and this appears to be possible via Python's exec() (I'll test this later). 

 

@Andrew Would you mind taking a look at the above, in case it might be a bug?

Link to comment

@Floating.Point This really is an interesting spot and thanks for the detailed video / workflow to download, makes my job WAY easier.

 

This is to do with how Alfred caches scripts within an e.g. Run Script object (specifically when using argv). Essentially, Alfred writes the script to a file which is then run directly with the passed argument using an NSTask. What's happening here is as no changes to the workflow and script are detected, the cache isn't being flushed until you edit the workflow.

 

If you switch the script mode to "with Input as {query}", then the script isn't written to disk and you won't get this caching issue.

 

I'll add an internal ticket as while there are a number of workarounds which can circumvent this issue, it's unexpected and confusing behaviour.

 

Cheers,

Andrew

 

 

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...