vitor

In a terminal: export PATH="/opt/homebrew/bin:/usr/local/bin:${PATH}" eval "$(brew shellenv)" osascript -e "tell application \"Finder\" to delete (POSIX file \"${HOME}/.pyenv\")" osascript -e "tell application \"Finder\" to delete (POSIX file \"${HOMEBREW_PREFIX}/bin/python\")"

When configuring a Run Script or Script Filter, Alfred provides a Language dropdown listing the runtimes which have historically been included with macOS. But what if you want to run a script from another language which you have installed on your system? Be it Node.js, Lua, or something else, it’s dead-simple to call them. Either: Save your script with a proper shebang (examples: #!/usr/bin/env node; #!/usr/bin/env lua) and use External Script as the Language, pointing to your script. Use /bin/zsh (or /bin/bash) as the Language and tell the runtime to call your script (examples: node MY_SCRIPT.js; lua MY_SCRIPT.lua). The first executes (marginally) faster but the second allows you to send preset arguments to your script. They work as they are assuming the languages were installed with Homebrew, as Alfred includes its directories in its PATH.

That one needs an update to work after the instructions. It’s already in the repo. Are you the same Bob? If so, please don’t split the conversation. If you need further help, you can ask in the GitHub issue.

If Obsidian is capturing the shortcut, you’ll have to change it in its preferences. Hopefully they’ll have a way to do it, and if not you should ask for it because that’s too simple of a shortcut to take globally.

@Serge @JamieKeene See the Updated Third-Party Python 2 Workflows GitHub page. It explains the situation, links to instructions on regaining access to Python 2 and includes a fixed version of this Workflow.

It’s served when the script ends, so the position of the delay does not make a difference. That is why in your World Cheater you can echo (in your case, cat a heredoc) sequentially and it works. You can’t serve two JSONs, only one. The reason you’re getting an error is that while you are spitting out two valid JSONs individually, what Alfred is seeing is the concatenated text of those. Two valid JSONs stuck together are not a valid JSON string. You can either add all your data at once (which I recommend; fewer moving parts) or you create a variable to hold your data as you modify it and print it at the end (which I do in the example, due to the timeout): #!/usr/bin/env python3 import time import json result = [] result.append({ "title": "Testing!", "subtitle": "testing script order of execution" }) time.sleep (5) result.append({ "title": "Testing again!", "subtitle": "testing script execution" }) print (json.dumps({ "items": result })) Or perhaps what you’re thinking is: #!/usr/bin/env python3 import time import json result = [{ "title": "Testing!", "subtitle": "testing script order of execution" }] time.sleep (5) result = [{ "title": "Testing again!", "subtitle": "testing script execution" }] print (json.dumps({ "items": result })) But that will only show the second one, which is expected. If what you’re looking for is to show one JSON then wait and show a different one, you don’t sleep in your code but tell Alfred (via the JSON) to rerun it after a number of seconds. You may also need variables to hold some data (e.g. so the script knows if this is the first run or a subsequent one). The Getting Started → Advanced Script Filters Workflow which comes bundled with Alfred has examples of both.

Welcome @Larrikin, I don’t understand what that means. Could you share the Workflow?

You have.

Follow the linked guide.

Welcome @RubyGoodbody, See Troubleshooting File Indexing Issues for ways to identify and fix the issue.

That is a good way. It’s “Method 1” in Understanding the scripting environment and perfectly appropriate for fixing it locally. I have sent a pull request with Method 3.

I agree! Which is why I prefaced it with qualifiers such as “seem” and “unlikely”. The beta which introduced this change was announced only recently. Again, no one predicted they would deprecate Python 2 in a point release. They handled PHP better. I do not understand your anger. You didn’t post in the right place to begin with and it’s back where it started. Nothing has been taken away from you. No, my reply was getting off topic. And because it was safe to assume you would want to respond, I didn’t want to derail that thread which is for user requests of Workflows to fix. You may disagree, but I don’t like when I’m subscribed to a thread and keep getting off topic notifications. I aim to extend that courtesy to others. If you frequent the forum, you’ll know I’m consistent about it. Which is exactly what is happening. The thread is still visible and at the top of new conversations in the main forum page. If anything, it’s getting more visibility. Just now it got another reply by another user. All I wanted was to avoid derailing a thread where I need to pay attention to every post to be able to help effectively. That is patently not true, and verifiable by anyone who frequents the forum. I am engaging you in good faith and would appreciate the same courtesy. That is not how this community works. To my knowledge, only spammers have ever been banned. But I will ask you to moderate your tone if you do decide to engage further. Alfred aims to foster a friendly community. Which is a valid choice. But please understand you are in the minority. I have always been upfront that the ideal outcome is for those Workflows to be updated but that requires the creators to do it. Or for the community to help. Both are happening as we speak and everyone is welcome to contribute.

Welcome @stephan420, See the following post which covers it. The two Python Workflows you linked to are already on the repo. As for the PHP Workflow, the cause is similar but you may want to ask on GitHub what they officially recommend. It seems to still be active.

@xilopaint The ship is sailing. I agree that ideally the library would be updated officially, and that the second best option would be for a forum regular (such as yourself) to coordinate a community-approved successor. But we can’t force either of those; the community of Python Workflow developers at large will decide, and right now they’re looking for something. So if you have a fork which you believe to be more solid than the ones being shared, I urge you to make it public and your intentions known in that GitHub thread. The longer you wait, the harder it will be for your alternative to gain traction. It doesn’t have to be perfect now, but it should be available. I’ll eventually have to update the libraries thread and I can only recommend what is public.

Respectfully, that is unreasonable and unfair. With only six posts in the forum, you don’t seem to be a regular. Otherwise, it is unlikely you’d have that view regarding Alfred’s community management. Every post in this forum—the official venue for discussion—is read, and it’s rare one does not get a reply. This could not have been completely avoided. (Most) Workflows are by third-parties and Alfred is flexible, it makes no demands over what language those people develop in. Many chose Python 2 because it is popular, shipped with macOS (Workflow developers tend to value minimal setup needed for users), and it continues to work. An overwhelming number of those Workflows were made when Python 2 was still supported and they weren’t updated (which is also up to the individual developer and contributors) because they didn’t need to be. Everyone knew Python 2 was going away; nobody expected it to happen in a point release. There’s little point in continuing to discuss that. Apple decided it and it is done. This wouldn’t have been disruptive if the Python team hadn’t botched the transition, but that too is done. They survived and learned. That is not in the slightest a reflection of Alfred’s underlying architecture, which uses the tools Apple provides. Finally, this is not scrambling. The workaround has been pondered and developed in a way to be the least disruptive to most people, getting them up and running fast without continuous futzing. The instructions install Python 2 in a self-contained fashion, meaning you can get rid of it easily and at any time. Ideally those Workflows will be ported, but that’s outside Alfred’s sole direct control. The community is discussing how to proceed. Reinstalling Python 2 and updating Workflows by request should help prioritise those the community cares the most for. I split the conversation into its own again because it’s getting too off topic and I want that thread to remain focused.

Welcome @NylaTheWolf, Precisely. The Workflow which does the searching should be where the random option is added. You may want to ask the developer to add it. If you use Pinboard, PinPlus does allow opening random “to read” bookmarks.

I’ve updated it since, in preparation for when Ruby gets removed from macOS. If you installed with Homebrew, you’ll be able to see the update.

@gniting Please don’t make new threads regarding others that already exist. It disorganises the forum and makes it harder to follow conversations and solutions. If you know of the original thread, post there instead. I’ve now merged yours with the original. Yes, you have to reinstall Python 2. Everything is explained in the top post.

They shouldn’t assume it. While is is possible for python to link to python3, code which relies on Python 3 should call python3—that’s the official name of the binary. Naturally, you are free to edit these to your heart’s content and build your own setup as you desire, but the updated Workflows listed here are updated in the way they can remain closest to the originals.

You have to. That’s what the final command in the instructions is for: ln -s "${HOME}/.pyenv/versions/2.7.18/bin/python2.7" "${HOMEBREW_PREFIX}/bin/python"

Added.

@michbsd Please don’t post in multiple places. That makes the conversation more difficult for everyone, including people coming after. @Smpl Technically it’s not using Homebrew, it’s using pyenv. But the reason is the same: installations are self-contained and don’t affect anything else on your system. If you ever decide you no longer want Python 2, you delete ~/.pyenv and the symlink and you’re good to go. In contrast, the download provided on Python’s website is a PKG installer which can do anything and will leave you with receipts. Plus, they don’t provide a v2 installer for Apple Silicon.

Welcome @mmm, Then I suggest a Run Script with /bin/bash or /bin/zsh as the language: case "$(date +%A)" in Monday) echo -n 'Mandag' ;; Tuesday) echo -n 'Tirsdag' ;; Wednesday) echo -n 'Onsdag' ;; Thursday) echo -n 'Torsdag' ;; Friday) echo -n 'Fredag' ;; Saturday) echo -n 'Lørdag' ;; Sunday) echo -n 'Søndag' ;; *) echo 'Not a valid weekday! Should never happen.' >&2 ;; esac

I missed zotconf in the fixes. ZotHero has a bunch of objects and doesn’t directly call python like most others, so tracking down everything isn’t as obvious. Fixed now.

There are multiple forum threads on this problem. Please use the search function before posting something new. You need only follow the instructions to reinstall Python 2 and the Workflow will be fixed. This particular Workflow has been asked about before.