vitor

I beg to differ! You correctly identified the problem and the solution, so you can do it. Someone else also found it and submitted a fix, but it was never included. Here’s what you have to do: In Alfred, right-click the Workflow → Open in Finder. Open the getfile.sh file in TextEdit. Make these changes. You’ll remove a / on line 6 and add one on line 11, do you see it? Save the file. You should now have a working Workflow, assuming that’s the only issue.

@davidrd85 If you are on an Intel Mac, have Homebrew, and run brew install jq in a terminal, the Workflow should start working. @gingerbeardman To make this work out-of-the-box for more people, you only need two changes (in all Script Filters): Add export PATH="/opt/homebrew/bin:/usr/local/bin:${PATH}" at the top. Change /usr/local/opt/jq/bin/jq to jq. Also, you can remove the #!/usr/bin/env bash shebang because it’s not doing anything; you’re already telling Alfred to run them via /bin/bash.

Thank you for the kind words. It’s possible, though I don’t have a tool to recommend. That won’t be added to the Workflow because it’s really niche and would essentially be a whole new Workflow. In almost a decade since the Workflow has existed, it’s the first time that has come up. Its purpose is to convert Markdown to BBCode for use in this forum; everything else (HTML and RTF) is icing on the cake. Even if you only wanted to keep those tags, you’d still have to purposefully ignore all others so they don’t remain in the final result and you’d have to make deliberate decisions on formatting.

Did you try :gdrebuildcache after updating to 2022.8?

Welcome @Pietro, Have you checked the troubleshooting steps?

Those variables go into the Run Script as environment variables. Otherwise Alfred would have to do all those substitutions (which could mess up your code) and they would not be available if you were calling external script. You need to do: curl -d '' "http://${server}:8001/command/${action}"

Welcome @cowansf, When making a request or a bug report pertaining to a specific workflow, please do not open a new thread to discuss your issue. Instead, use the Workflow’s thread and make sure to include any debugging. From your error, you seem to not be on the latest version (2022.8). Please update. If you are on the latest version and still see the error, please follow the instructions above to post your issue. Thank you. Locking the thread so we don’t split the conversation.

Welcome @davidrd85, Open the debugger and try again. It should tell you what’s wrong, and that’s crucial information to help you.

Update. Better handling of code blocks with Markdown syntax highlighting. To update, download the latest version (same URL) or wait a few days and it’ll prompt you to on next usage, since it uses OneUpdater.

On a Workflow with multiple manual steps, you may find it useful to access recent clipboard history in order to pass along previously copied data to the next stage. But if you switch context to the Clipboard History Viewer, you lose your place in the Workflow. To avoid that, you can load your history into a Script Filter and place it between the relevant steps of your Workflow. This post provides working code to do just that. Things to note: This works by directly accessing Alfred’s clipboard history SQLite database, so it can be considered a hacky solution. Use at your own risk. That said, it only reads data. By default it shows the 40 most recent items from the clipboard history. Look for LIMIT 40 in the script to change that value. Only text entries are considered. Everything else is ignored. The code does not limit you to the clipboard contents. If you type something, that will be used instead. Paste the code in a Script Filter without a Keyword, Argument Optional, and Language set to /usr/bin/zsh --no-rcs. if [[ -n "${1}" ]] then /usr/bin/osascript -l JavaScript -e 'function run(argv) { return JSON.stringify({ items: [{ title: argv[0], arg: argv[0] }] }) }' "${1}" exit 0 fi /usr/bin/sqlite3 \ "${HOME}/Library/Application Support/Alfred/Databases/clipboard.alfdb" \ "SELECT JSON_OBJECT('items', JSON_GROUP_ARRAY(JSON_OBJECT( 'title', item, 'arg', item))) AS JSON_RESULT FROM ( SELECT item FROM clipboard WHERE dataType IS 0 ORDER by ts DESC LIMIT 40)"

As of Alfred 5, this is no longer necessary. Use the skipknowledge key. In the Script Filter JSON format, setting a uid makes Alfred “aware” of an item, meaning it will be sorted according to Alfred’s knowledge next time it shows up. It also means your position in the results list is preserved when the Script Filter reruns during the same session. On rare occasions you may wish for the latter without the former: results which are displayed in a preset order (ignoring Alfred’s knowledge) while keeping your position in the list. Session variables make that possible. For clarity, I’ll use ENV[varName] when referring to an environment variable and varName when referring to a variable (or preferably constant) in your code. Check if ENV[uidSeed] exists. If yes: make uidSeed with the contents of ENV[uidSeed]. If not: make uidSeed something unique. Good pick: random number. Better pick: current date and time. When outputting the Script Filter JSON, prepend uidSeed to the uid of every item and set it in variables. The result: if your Script Filter was just launched the steps above will execute 1 → 3 → 4, but on every rerun they will be 1 → 2 → 4. This creates what we sought: results which are aware of themselves only during the current session. Below are working snippets to accomplish the first three steps. Swift: import Foundation let uidSeed: String = ProcessInfo.processInfo.environment["uidSeed"] ?? String(describing: Date()) JXA (JavaScript for Automation): const uidSeed = $.NSProcessInfo.processInfo.environment.objectForKey("uidSeed").js || Date.now().toString() Ruby: UID_SEED = ENV['UID_SEED'] || Time.now.to_s Python: from datetime import datetime import os uid_seed = os.getenv('uid_seed') or str(datetime.now())

Alfred’s default results have a deliberate and predictable scope which ensures they are fast to retrieve. In contrast, Workflows deal with arbitrary data either off or online, can show large amounts of entries, and their speed depends on many factors outside Alfred’s control. Thus, by design, Workflows need to be intentionally invoked and cannot interfere with the default results. Still, you may have a particular Workflow so central to your routine that you’re willing to forego the default results in its favour. If you understand the tradeoff and wish to proceed, you can achieve it via Invoke Alfred with Workflow. All you need to set it up is explained in the notes: choose a Hotkey and insert the desired Workflow’s keyword in the Show Alfred Utility. You’re done. Use your new Hotkey and Alfred will open with the query you want. By default the text is selected, allowing you the quick option to start typing to overwrite and search something else. In most cases, the three objects at the bottom may be ignored or deleted. They exist in case the Workflow you want to call relies on External Triggers instead of keywords.

Welcome @ldlework, Your question isn’t Alfred-related; it only concerns JXA behaviour. Have you tried somewhere more general, like Ask Different? Quite possibly. JXA has quite a few things left unfinished. The folks at the JXA Cookbook might have an insight on this particular case.

Welcome @Un4given, Your GitHub repo contains Python code, but the Workflow itself contains and runs a binary. Its signature is adhoc, so it won’t run on other users’ machines without showing the macOS prompt about it being potentially unsafe. Plus, it’s only compiled for x86_64 so it won’t run on Apple Silicon without Rosetta. And it looks like you may be shipping a whole Python distribution with the Workflow? That considerably increases its size. To solve all of those, you can instead call the original script via python3. If the user already has it it will work immediately, but if they don’t macOS will allow them to install it in two clicks.

Added. Thank you for checking.

I see zx depends on node, so you need to have it accessible too. Whatever environment you have set up in your shell’s startup files which makes node and zx available, you’ll have to replicate in the Workflow. That might be as simple as adding export PATH="/opt/homebrew/bin:/usr/local/bin:${PATH}" at the top or it might require something else if you use a node version manager. See understanding the scripting environment for an explanation and other options.

To make sure we’re on the same page: ⌘L invokes Large Type inside Alfred, not across the whole of macOS. If Alfred isn’t showing, ⌘L will not trigger Large Type. The fact that you’ve remapped the shortcut in Safari makes me think you’re expecting the shortcut to work anywhere. That is indeed possible. In addition to using the Universal Action, you can build a Workflow: connect a Hotkey Trigger (change Argument to Selection in macOS) to a Large Type Output (default settings) and you’re done. That way you can have ⌘L trigger Large Type anywhere, if that’s what you’re after.

Welcome @Trinition, See the following post by @Vero on why it happens and how to solve it.

Welcome @sirris, What does the debugger say?

Ah, forgot to correct something above. theFiles[1:] should be theFiles, because you no longer want to ignore any element (with sys.argv, you’re ignoring the script itself from the array). Fix that and you should be good to go.

Close; you have a few mistakes. theInput = "{argv}" should be theInput = "{query}".sys.theFiles[1:] should just be theFiles[1:]. sys.argv is an array that contains the arguments passed to a script; if you already have another array you call it directly, no sys.. Also, you can get rid of theInput and do theFiles = "{query}".split("\t") directly, no need for the extra variable. Correct. Set the object’s configuration in the object itself via the GUI. It’s nice that the option exists to set and override the configuration via JSON, but that’s an advanced option most people will never need to touch. Wouldn’t that imply you were against technology? That’s the opposite of how I see you, you’re trying to learn! But it bears repeating: you should be using with input as argv, not with input as {query}, and be passing your files as proper arguments, not tab separated. To avoid an XY problem, be sure to always include your goal as part of the question, above the method you think will get you there.

Update: Add delay on scheduled runs, in case Google Drive path exists but is being mounted.Better skipping of unexistent paths.Replace External Trigger for launchd with Inbound Configuration.Simplified :gdlaunchd installation internally.Added machine architecture type to diagnostics.

That comment is over two years old. It no longer applies, the Workflow has had 20 releases since then.

Alfred is passing through the arguments, not path. The latter is like if you had set the value manually in the Action in Alfred, which is not what you’re looking for. Speaking of which, why not configure the object directly via the GUI instead of overwriting it via JSON? Action in Alfred is simple enough that if you’re feeling the need to override its configuration, you’re probably hiding extra complexity somewhere else. If you truly need different Action in Alfred configurations in the same Workflow, consider if multiple objects won’t be a simpler solution. Anyway, to pass multiple arguments send them via an array in arg: config = { "alfredworkflow" : { "arg": sys.argv[1:] } } The above assumes with input as argv, which you should use instead of with input as {query}. It uses from argument 1 to the end because in python argv[0] is the script itself.

Updates. Removed support for the alternative app. It offered a slightly nicer-looking interface for adding bookmarks but in return it was bigger, slower, and used Electron which is constantly changing and part of an system rife with (security) issues. While it’s unlikely that would ever become a problem (due to the limited scope of the app), removing it entirely is a better bet. It didn’t have a tremendous amount of downloads either way, so I doubt it will be missed much. In its stead, the default option to open the window directly in the browser is now marginally faster. Also, the External Trigger for the launchd job has been replaced by an Inbound Configuration. If you used it, you don’t have to change anything. To update, download the latest version (same URL) or wait a few days and it’ll prompt you to on next usage, since it uses OneUpdater.