vitor

You’re probably facing this issue (link has solution).

Add an Arg and Vars Utility with one file path per line in the argument. Connect it to a Split Arg Utility splitting on newlines to arguments (not variables). Connect that to the Automation Task.

Also worth noting that by default Alfred passes multiple files as multiple arguments. So if you don’t need to save them to a variable for later processing (@Stephen_C’s workflow does) you may be able to just connect the objects. Let me be more specific: if you connect a Universal Action directly to that Automation Task, it’ll just work with multiple files. It’s only when you need to do stuff in between (meaning you need to save the file list to a variable) that splitting later comes into play. For that case, see @Stephen_C’s linked workflow. Also, just to round off the information, when applicable the output of Automation Tasks is also multiple arguments. In the case of that Automation Task, the output is the final paths of the files, each in an argument. In other words, you could have Universal Action → Automation Task to Copy Files → Automation Task to Move Files → Automation Task to Trash Files and it would all work, doing each action in sequence.

You can build it. Connect a Universal Action to the Path Basename Automation Task, then to a Copy to Clipboard Output. Done.

Did you mean to have a link for other people to download and try the workflow? Quick tip on the screenshots: macOS can take screenshots of individual windows, preserving their shadow against a transparent background. Press ⌘⇧4 and your cursor will turn into a crosshair. Now press space and it will change into a camera icon. Move it over a window and it will get a blue overlay. Click to take the screenshot.

$PATH isn’t a special value, it is interpreted by the shell. In any other language the syntax would be different. Reading it as a string literal is the only correct behaviour for that case. The PATH Alfred uses is listed in the linked page, so if you want to append to it you just need to add those. OR, as it is more common, you add it in the Run Script itself: Well, yes, that wouldn’t work anywhere. A shebang is a clue for which interpreter to use when one isn’t specified. But you already specified one, /bin/bash, so the shebang is ignored. This is not an Alfred quirk, it would work the same in a terminal. If you write PHP code but tell Bash to execute it, it’s normal that it produces an error. You’re doing the equivalent to /bin/bash myscript.php but shebangs are only interpreted in cases like /path/to/myscript.php. See Calling non-standard runtimes from Alfred for the proper way to do it. Again, this is how it would work in a terminal too. Alfred isn’t doing anything weird. In fact it is adhering to the letter to how this is expected to work. This is the Unix model that has been in place for decades and is used by all well-behaved software. Because, as explained in the first link and the previous post, that’s how you get code which is broken and hard to diagnose, when everyone has different setups. Emphasis added:

The answer is in the post right above yours. Google broke the functionality and as of now it’s uncertain if they provide an alternative.

It is likely RStudio is auto-copying text when you select it, and thus when you press the shortcut it’s triggering the merge. See the KB article regarding iTerm, as the solution to try will be similar.

They have not. It’s unlikely it’ll happen unless enough people ask for it.

Welcome, They aren’t incompatible, the solutions are at the end of that article as is the reason why this choice was made. Workflows aren’t broken by it, they would be if the reverse were true. If Alfred read your environment, workflow sharing wouldn’t work predictably between machines because you’d need to replicate the other person’s environment. By setting it to a standard, you can be more reasonably confident it will work. You can change the PATH, it is not fixed. Before Alfred 5, it was common for developers to extend it (method 2) if the workflow had a dependency on some Homebrew package. That works the same today. If you find a workflow with /usr/bin/php, you can change it. Edit the workflow itself and/or submit a PR. Furthermore, for tools managed by macOS, developers should use the absolute path like /usr/bin/python3 if that works for their workflow because it ensures a more predictable experience that the developer can debug. Almost nothing in computing is all bad or all good; it’s always a tradeoff. More than a decade of Alfred development and evolution with the community informs these decisions. In your own personal workflows you should do whatever you prefer. Workflows which are shared with the wider community should adhere to a standard that will work for most people. Homebrew is the de facto package manager for macOS. It’s what most people know and use and even the people who use an alternative package manager know of it thus have the chops to work around it. Furthermore it is self-contained so there’s not really an issue to having it alongside another package manager for use with Alfred. It’s also the package manager that gets the most attention from Apple. I could go on, but what matters is that it was a pondered decision, and Homebrew came out by far as the best choice for this case while still not stopping you from using something else if you so choose. That was a bit long but I hope it helped to clarify. Have a great week!

Nothing has changed about the detection. And without having access to the browser, there’s no way for me to investigate further. I can tell you the detection works by checking if the kCGWindowLayer of a window is 0 and if its kCGWindowOwnerName starts with the name of a known web browser. In other words, it doesn’t matter if it’s called Orion, Orion RC, Orion Beta, or Orion The Huntsman Browser, they’ll all be detected. That may help you figure out what changed. Also try using the Webkit Browser Automation tasks and giving it specific names.

Indeed there is. Right click the Script Filters and in the context menu, near the top, you can disable “Treat Input as Universal Action”.

Welcome @illegalhex, Understanding the Scripting Environment explains everything.

Each item is a separate keyword and Alfred will learn your usage like with other keywords. In other words, the items you choose more will bubble to the top. You can also do some advanced tricks to guarantee they show up when typing certain parts of the keyword. See “Keyword Latching” in Understanding Result Ordering.

The fuzzier the search, the bigger the performance implication. Have you considered a workflow with a Universal Action (keyword “mail”) connected to an Action in Alfred set to Jump to Mail to…?

For reference, it doesn’t have to be JavaScript. While JSON did start from JavaScript, every major language nowadays handles it. At the end of the day it’s just text with a specific structure, you can even write it by hand. In the dte Script Filter, delete the last line and add instead: cat <<EOF { "items": [{ "title": "$(get_day_of_week "$input")" }] } EOF For more information, see Script Filter JSON Format or the Getting Started example workflows (press + on the bottom left, in the workflow list).

@MM00 Use the fork by @giovanni.

Make sure you’re on version 2024.1 of the Automation Tasks. Also, I need to know which ones are failing, with which error, and your Alfred and macOS versions. But again, Orion RC isn’t generally available so it’s only supported in a best effort basis. If I can’t access it, I can’t diagnose it either.

Thank you, that was useful. Update to 2024.1 and it should be fixed.

2024.1 New Task: Extract PDF Text. Trash: Add option to trash via Finder or system API. Open Apps: Fix description. Front Browser Tab List: Fix getting list.

To open a new window specifically, there’s an Automation Task for that.

Updated to 2024.1. Add Universal Action to install from ipsw.Capture system keys when running VMs.When deleting VM, remove it from ignored list.Hide Alfred before starting VM.Shorter Objective-C functions.

Yes. You shouldn’t need those anymore. Reminder, as @Vero pointed out above, to not let an uninstaller clean Alfred’s files as they will likely delete what’s needed for Alfred 5 too. Glad you’re sorted, have a nice weekend!

In addition to @Vero’s instructions, and you should follow those first, the way you’re starting the Alfred Preferences is atypical and seems to be a custom method. I wouldn’t be surprised if that’s somehow linking directly to the v4 preferences app (but can only say for sure by looking at whatever workflow you’re using). Instead, use one of the standard methods to open preferences.

with input as argv does not mean “use $1”, that’s just how Bash and Zsh determine the first argument. You have to use the appropriate syntax for each language. When you make a Run Script and change the language, Alfred shows example code that tells you how to do it. In AppleScript it’s item 1 of argv. Please avoid pinging directly in new posts, as there are many people who are able and eager to help with basic questions but may get discouraged if they see a direct request. You learn best by teaching, so I encourage others to participate. In addition, please use the “Workflow Help & Question” for these queries (I have moved your post). The Advanced Rips & Tricks posts should be kept without replies so as to not cause confusion.