Andrew

@onewheelskyward are you on the general release of 3.8 (build 959)? If not, update to this and things should work. If still not working, and if Finder and Terminal are selected in the Automation settings, then try restarting your Mac. In one of the 3.8 pre-releases, I had updated to Xcode 10 without adding the required NSAppleEventsUsageDescription for automation, so if you updated through that pre-release, it may have confused your Mac. Cheers, Andrew

@deanishe I think my original reasoning is following the behaviour of Finder, but I can absolutely appreciate that Alfred has grown way beyond the original vision. And now workflows are a significant part of Alfred, the paradigm has shifted and modifier alternatives are normal. I had already thought about when Alfred is configured for Spotlight provide contact data, and I'm going to leave that to be treated as a file for now, otherwise it would need a "fudge" outside of Alfred's framework (to treat it differently to the Contacts system workflow where I can just wire in an alternative action). This view may change though.

@deanishe It's a fair point - I'll add a note

This is the default configured shortcut for the default results too (in Alfred's Advanced preferences) - Reveal in Finder.

I've just pre-released 3.8 b958. If you're on the pre-release channel, update now!

cmd+o is a standard shortcut throughout macOS, for example, cmd+o on a file in Finder will open it. Alfred adopts cmd+o to "Open" any file which may otherwise have an action. These actions include: - Showing contacts in Alfred, cmd+o will open the contact in macOS. - If the File Search > Navigation shortcut has been set so that return navigates into a folder, cmd+o will open that folder in Finder. etc. Cheers, Andrew

@Rebecca if you could update to the latest 3.8 pre-release and let me know how you get on. Note: macOS will request access when Alfred needs access to these things. Alfred should be in the "Accessibility" section for Snippet Expansion. Cheers, Andrew

@TheJesusFish @Rebecca If you could update to the latest Alfred 3.8 b958 pre-release from Alfred's update preferences and let me know how you get on. In the latest version of Google Chrome, when Alfred used the Apple Accessibility API to get information about the currently active text field, Chrome was returning different / random process identifiers for each keystroke. I've made a tweak which should work around this apparent Chrome bug. Cheers, Andrew

@gta91 which build of Alfred 3.8 are you using? I did a tweak in b957 with relation to automation and Apple Events which should fix these types of issues. Cheers, Andrew

Hi All, Just to let you know, I've just pre-released 3.8 which has been configured with a hardened runtime, which is a prerequisite for Apple's Notarisation process. I'd appreciate it if people who are updating to Alfred's pre-releases (from Alfred Preferences' Update tab) could let me know in this forum thread if they run into any issues with this update, for example, workflow scripts which worked in the previous pre-release not being able to run. I'm hoping to have the notarised version of Alfred 3.8 generally released within a week or so. Big thanks! Andrew

I just thought... it's worth adding that you do actually see the appended newline from osascript -e 'return "~/Downloads"' in Terminal. When using bash and echo -n, the next command is immediately after your output. Cheers, Andrew

@CJK Alfred doesn't process the output of a Run Script object in any way, and osascript non-optionally appends a newline to any output (which could be seen as an osascript bug, but I suspect this behaviour will never change). You have a couple of options: 1. If you switched your script to bash, then use echo -n for output, you'll get the output as expected. 2. Add a Transform utility object after your Run Script set to trim the output. This will remove the newline from your osascript. This has come up before, and my opinion remains that Alfred shouldn't automatically process the output of ant Run Script objects (e.g. to trim), as this would lead to more unexpected behaviour than not. Cheers, Andrew [moving to workflow help].

@nindustries This should work fine - could you open Console.app and see if there is anything interesting logged out when this happens?

@bmazin If you drag a file into Alfred's default scope, it does add the containing folder - This is to just make adding folders to the scope easier. Obviously, once ~ is in Alfred's scope, it's going to search everything within ~. When manually adding all the folders, did you try adding in all the finite ones (dot prefixed)? Also, I see you have some Box sync items there, I'm wondering if these are having an affect. @bmazin - Could you pop an email to our info@ address, I'm going to give you a build which will log the actual folders Alfred is including in the scope when folders in home is selected on your Mac. This should let us know where the discrepancy is. Cheers, Andrew

When you tick for Alfred to include folders in home, Alfred enumerates the folders (NSURLIsDirectoryKey) in ~/ with the filter "NSDirectoryEnumerationSkipsHiddenFiles", and also excludes the suffix "/Library". The returned list is added to the list of manually added items in the search scope, and should be no different to manually adding these folders yourself. What we need to work out is why, in the case of your two Macs, there are additional folders being added which are subsequently resolving through to where your Mail attachments are being stored (~/Library/Mail/). I have a few theories, perhaps NSDirectoryEnumerationSkipsHiddenFiles is failing and Alfred is also adding a hidden folder which is somehow linked through to the mail folder, but it's extremely difficult for me to investigate this without access to your Mac. If you open Finder to your home folder, then use cmd+shift+. this will show all hidden files and folders. Perhaps start adding in the hidden folders to Alfred's default search scope (with home folders unchecked) until this problem is exhibited, this will give us a clue where to start looking for the culprit. Cheers, Andrew