vitor

Open Alfred and press the up arrow on your keyboard.

2 hours ago, wrjlewis said:

I presume this is because python 2 is no longer shipped with Mac OS in this version as its deprecated. 

That is exactly what’s happening.

2 hours ago, wrjlewis said:

I’ll need to update the workflow to use python 3, but this is not shipped with Mac OS either as far as I’m aware and running python 3 in a terminal would prompt the user to install developer tools (containing python3).

Again, correct.

2 hours ago, wrjlewis said:

I need to investigate if that would mean the workflow wouldn’t work until a user did this, if anyone here knows please share? It would be great to have no additional steps when using this workflow. 

Just invoking python3 is enough to trigger the prompt to install the CLI tools, and it will be a GUI prompt. A user with Homebrew installed will already have those installed.

Is that an additional step? Kind of, but it’s a one-time thing that is over in two clicks, it’s pretty straightforward, and not everyone will need to do it.

For reference, the version will be 3.8.9.

3 hours ago, wrjlewis said:

For a short term fix, install python 2 if possible.

That won’t work for the current state of the Workflow. I mean, they can install Python 2 but not to the location where it was because that’s protected. You have to at least expand the PATH in the Workflow before calling the script:

export PATH="/opt/homebrew/bin:/usr/local/bin:${PATH}"

To install Python 2, @AlexUfa could install Homebrew, then:

export PATH="/opt/homebrew/bin:/usr/local/bin:${PATH}"
eval "$(brew shellenv)"
brew install pyenv
pyenv install 2.7.18
ln -s "${HOME}/.pyenv/versions/2.7.18/bin/python2.7" "${HOMEBREW_PREFIX}/bin/python"

That installs pyenv (a Python version manager), then the latest Python 2, then links it to the Homebrew prefix. They could also try the old Homebrew formula, but that won’t work on Apple Silicon without modification.

1 hour ago, AlexUfa said:

Yes, macOS 12.3 still in beta.

I highly recommend you avoid installing beta operating systems (especially macOS) if you’re not at ease debugging and fixing these kinds of issues on your own. Beta OSs are unstable and things stop working all the time.

1 hour ago, AlexUfa said:

But I'm afraid while I tried to install python 3 and solve this problem I did a lot of wrong settings

Plus, you get into those types of situations. You can’t get out of it by installing Python 3, because it’s incompatible with Python 2 scripts.

Naturally, if you want things to break because what you care is the experimentation, more power to you!

Phoenix might, but it’s not exactly easy to set up. Powerful, though.

This sounds like a feature request for Magnet. Technically you could use AppleScript via Alfred to move the windows to new positions, though figuring out which windows to move might be tricky (maybe not, since apparently you’re already keeping track).

But if you’re already using a window manager to do specific things, using it for that step would make sense.

Start with List Apps for a Workflow which already lists your apps via a Script Filter. Delete the Open File and add a Delay Utility plus a Dispatch Key Combo Output.

You’ll always have to type some keyword or use a different Hotkey to invoke it. You can’t have it work on Alfred’s default shortcut, because arbitrary shortcuts don’t run there—that could make slow Workflows affect normal operation.

Kind of, with a Fallback Search Trigger. That won’t run a Script Filter without pressing ↵ at least once, otherwise a slow Workflow could interfere with Alfred’s normal operation.

What you can do for your use case is make the Workflow with a Hotkey and use that instead.

@gmile Understanding the scripting environment expands on @luckman212’s point.

1 hour ago, andy4222 said:

My PATH has:

export="/usr/local/lib:$PATH"
export="/usr/local/lib/node_modules:$PATH"

This is incorrect on several levels. You’re making a variable called export, which doesn’t alter PATH. Even if the code were correct (export PATH), adding those directories doesn’t make sense. PATH is about executables, not libraries.

We can’t comment on what your Workflow needs without seeing it. In general, you should package its dependencies within it, not install them globally.

Perhaps Understanding the scripting environment will give you a clue to understand how things work. Your current mental model seems confused.

11 hours ago, Undertaker01 said:

I have not changed anything since I installed this workflow and I'm just now getting this error after it working fine for a long time.

Yo’ve changed plenty of things, only outside the Workflow. One of your apps is the likely culprit. When it happens, run osascript -l JavaScript -e "Application('System Events').applicationProcesses.where({ backgroundOnly: false }).name()" in a Terminal and check what’s running.

Also:

• Make sure you’re on 22.1, just released (basically code cleanup).
• When asking for help, always include your Alfred and macOS versions.
  

Just now, Tsunami said:

Given that /usr/bin/php was removed in macOS 12.0 and it's still in the dropdown, probably none.

Yep. Pretty much. The workaround might be different because Homebrew no longer ships Python 2 in the core tap. As for its impact on Workflows, we’ll have to wait and see. (In the grand scheme) There weren’t that many popular ones written in PHP and still working, and for a while now new Python Workflows (that I’m aware of) have required Python 3, meaning many people won’t even notice.

@deanishe’s older Workflows (and Workflows using his library) may be affected because (unless I’m misremembering) his Workflows always used the builtin-in Python (thumbs up; no dependencies and fewer instructions) until he abandoned it for Go.

Untested but should work.

@nesdroc Thank you for the kind words. I cannot reproduce the problem, so my post right above yours still applies.

11 hours ago, nebaon said:

the function implementation is a bit beyond my capabilities.

It’s literally pasting that code without changes. Follow my instructions and the resulting Run Script object will take your input and spit out the encoded text for the next object, just like if it were another utility.

Just now, Grug said:

On Macos BigSur, it open Skype

Shortcuts doesn’t exist on Big Sur. No idea why Skype wants to handle that file extension on your machine, but that’s not something I have control over.

This older version of the Workflow works on Big Sur.

10 hours ago, Chris Messina said:

is your position consistent with this upcoming change in macOS Monterey 12.3 Beta?

Yes. Python’s transition has nothing to do with Apple and that change isn’t news. Though it is bad form of them to do the deprecation in a point release rather that a major release.

6 minutes ago, virpio said:

Alfred invoking the scripts so that they are running from inside that folder

You may also be interested in External Script as the Language.

7 minutes ago, virpio said:

Having even just a button that would open this folder

It’s the square to the left of Cancel.

That’s a feature of the language. It wouldn’t make sense to have it as part of the UI because it’s a piece of code like any other.

It depends on your Workflow. By using a Run Script Action with Language /usr/bin/osascript (JavaScript), you can encode the input with

function run(argv) {
  return encodeURIComponent(argv[0])
}

Or, if you know the only thing you will need to encode are the spaces, use a Replace Utility.

Currently there is no way to do it. This is a duplicate, so please continue the conversation in the original post if you have anything else to add.

Don’t make your password available in plaintext for every app to see. You can restart without a password by using an AppleScript Run Script Action with tell application "System Events" to restart, or better yet just use a System Commands Action.

Save the bash script to the Workflow’s root directory, then just source script_name before calling your functions.

11 hours ago, Chris Messina said:

It might be nice if the information you shared about python2 vs python3 were available in an info button

The transition from Python 2 to 3 took over a decade and is extremely well-known (in the whole field) for how annoying it was. Even basic tutorials these days are likely to mention it. If it was news to you, that is both a fluke and good news.

11 hours ago, Chris Messina said:

or perhaps Alfred could indicate which version of python is being selected with subtext in the menu.

That would be clutter. It is the purview of the person programming to determine that because it depends. It isn’t hard at all and you figured it out. That is good, and if you plan on writing more code you absolutely must get used to it. From here on out it only becomes more complex and there is no handholding. Learning how to understand what’s happening and how to fix it will be a crucial skill.

11 hours ago, Chris Messina said:

I'm not sure I would have figured out why my script wasn't working without your guidance.

I don’t believe that. You did figure it out. Right on the first post you mention the different versions! Then you took the correct next step: tried to fix it yourself and asked for help when you felt you were at your limit. Good job! Now you’re programming; that’s all part of it. Do you think I or Dean never have questions? Everyone relies on other people sometimes.

I didn’t want to overwhelm you on the first reply and do think that at this point you’ll benefit from experimenting and making mistakes, but the fixes we offered you are documented. At some point in the near future it will be useful for you to understand that model.

12 hours ago, Chris Messina said:

As it stands, without some kind of disclosure, it seems like Alfred is implicitly endorsing the use of the system python library since there are no warnings that it's deprecated.

The situation isn’t as clear-cut as that. Try Ruby in the Terminal and you’ll get a scary message too. Should Alfred also warn about that? Definitely not! The only reason the message exists is Apple put it there. We didn’t need to be in this situation; we are because they chose it.

It’s irrelevant to discuss that at this point. The Alfred community has known of these deprecations from the start and the path forward is implementing a solution, not adding caveats to the old method.

3 hours ago, deanishe said:

I think that's the wrong workflow…

It definitely is. I made that one over three years ago.

@gohoyer That solution takes the long way around and uses a deprecated tool. @donnoating mentioned they know how to do it with launchd; that’s the correct and most straightforward tool for the job—it’s even recommended in the link you posted.

39 minutes ago, donnoating said:

I could do that using launchctl

And you’ll have to. By design, Alfred Workflows have to be purposely called, there’s no facility to auto-run them on their own.