deanishe

Don’t set rerun if there’s no value. rerun = None ... ... if rerun: feedback['rerun'] = rerun ... ...

And then delete the rest of the script.

The app may be registering that you still have your finger on CMD and be executing CMD+Backspace instead of just Backspace.

The default PATH does not include /usr/local/bin I assume you're talking about your shell's PATH. That only applies in your shell (and programs you execute directly from it). Your macOS user session doesn't care about your shell's environment, and neither do Mac applications. The default PATH, as used by Alfred and all other Mac apps, is /bin:/usr/bin:/sbin:/usr/sbin (or something similar — I'm writing from memory).

Yeah. Python 2 was EOL'ed in 2020. It would have been a bit questionable to start a new workflow in Python 2 after that. The death of Python 2 was always going to be a big problem in workflow land, but Apple removing Python completely is a real kick in the nuts. I suppose the sensible thing to do going forwards is to target Homebrew Python. Most users are going to have to install Homebrew, anyway.

Yeah, this bit isn't true: Workflow developers writing Python mostly switched to version 3, so chances are you won't notice the change. Most workflows are written in Python 2 because it was part of macOS. Python 3 has always required installing some form of dev tools (i.e. it's a pain for users).

Only the most trivial Python 2 programs run unchanged under Python 3. That might include a fair few Workflows, however. But no, just pointing Python 2 programs at a Python 3 interpreter isn't a solution. This is going to be a huge shitshow, imo. Most workflows will need rewriting and all users will need to install developer tools. Until Andrew adds some kind of PATH-altering feature to activate Homebrew, the best way to use Python 3, imo, is to use a shell wrapper and alter PATH yourself: export PATH=/opt/homebrew/bin:/usr/local/bin:$PATH python3 myscript.py In any case, it'll still be a pain in the backside for users because there's no way around installing some developer tools. JXA is probably the only straightforward way to write workflow scripts any more. Python and PHP are gone, Ruby's days are surely numbered. Compiled workflow binaries require signing to avoid stupid, scary warnings. JXA is probably the only semi-sensible language that will remain part of macOS.

I can't tell you anything from 1.5 error messages. Please provide the full error report from the workflow debugger and/or log files. Bear in mind that this workflow is abandonware. If it's not compatible with your version of Safari, I'm not fixing it.

The library isn't Python 3-compatible. The plan was to rewrite the whole API for Python 3. There's a lot of Alfred 2-vintage crap that can be thrown away. Now I'm thinking I should release a Python 3-compatible version of the existing one. Because the library uses Unicode throughout, it's possible that some workflows based on it might work on Python 3 with just an updated version of the library. Broadly speaking, I'd imagine every Python workflow needs at least the shebang/interpreter path changing, and a very large proportion will also need code changes. Hard to say for sure. Anyone who was doing text handling properly in Python 2 (i.e. properly decoding and encoding text) will need to fix their workflows. Anyone who was just using bytestrings may not need to change any code.

I think that's the wrong workflow…

You can pass a list of strings. They will either arrive as multiple arguments (in ARGV) or as a single tab-delimited string.

Sure, but different applications have different requirements. In particular, Alfred leans very heavily into the filesystem-as-an-API idiom, including its public API that an entire decade’s worth of workflows and tooling – almost everything the community has ever contributed – depend on. Other apps can change and tweak their sync all they want because the data are private: nothing else needs to be able to interact directly with their on-disk files. But Alfred can't change the way it uses the filesystem because manipulating Alfred's files is effectively part of its public API. Maintaining that API must take priority, and there's no obvious way it can be altered to compensate for crappy filesystems in a backwards-compatible way. It sucks that Alfred doesn't work reliably with iCloud/Google/One Drive, but in 2012 it was simply not foreseeable that Apple, Google or Microsoft's virtual drives would never work as well as Dropbox already did.

Same here. It wouldn't be such a problem if Dropbox weren't such preposterous bloatware. I don’t think iCloud/Google/One Drive will ever be up to the job. At the end of the day, they’re just not meant to be that good at syncing. They're designed for Word documents and photos, so they don't work very hard to avoid conflicts because the user can solve them. Dropbox was specifically designed to provide a "backend" for applications like Alfred, and tries very, very hard not to break the application by mangling its internal data. For that use case, Apple, Google and Microsoft all have other proprietary products or services they'd like to sell you. I've had more luck with Syncthing. It syncs well and fast, and is super lightweight compared to all of the above.

It's the simplest way to handle them, tbh. If you process symlinks, you need logic and a bunch of memory to avoid any loops (i.e. a symlink that points to one of its own parent directories). There isn't really a good way to handle them, imo. Different users want them to be handled in different ways. It sounds like you need to fix Google Drive, though: It seems unlikely that using the workflow is the only time you'll have issues with unstable GD paths.

The workflow contains an unsigned binary. All the message means in practice is that the developer didn't pay Apple to not show that warning.

Yes. It won't work otherwise.

That’s easy enough to check, isn’t it? /usr/bin/python is always Python 2. Python 3 is /usr/bin/python3 (and part of the developer tools, as Vítor noted). The best thing to do with Python 3 is to use bash/zsh and set export PATH=/opt/homebrew/bin:/usr/local/bin:$PATH at the top of the script. Then call your workflow just using python3 (e.g. python3 myscript.py "$1" or with the shebang #!/usr/bin/env python3 That way, the workflow should work with either Homebrew Python 3 or the one from Apple's developer tools. You shouldn't use Python 2, even though it is installed, because it's dead. It will never be updated again.

It’s just cat /path/to/file.json

It's similar, but you don't have to (can't) explicitly pin/unpin the clipboard viewer. Alfred could also automatically select the next entry when you paste but don't close the clipboard viewer.

Perhaps there could be alternative hotkeys, say ⌥↩ and ⌥⌘#, to paste the selected item and keep the window open?

The app that isn't turning off secure text entry is (almost) guaranteed to be something with a password field (otherwise it'd have no reason to turn it on in the first place). Start looking at applications where you have to log in (browsers, password managers, etc.).

Thanks for the explanation, Vítor 👍

TBH, I’d be tempted to rip out all the code that puts results in environment variables. Or add quite a lot of comments to the script. It’s not exactly easy to follow (if you're using it as an example to base your own workflow on). I don’t understand what the Seed is for.

That's the developer of the workflow you're insulting.

If there's a problem with the workflow, post about it in the workflow's thread where its author will see it.