deanishe

Looks handy. The GitHub URL is a 404, unfortunately. A couple of suggestions for possible improvement: It'd be better if you could move the configuration into a separate file. There are standard locations for such files. The reason is that any update to the workflow will overwrite the user's config. The simplest way would perhaps be to add another action that creates the config file if necessary, and then opens it in the user's default editor (open /path/to/config.sh). You could use export TOKEN=xxx in the config file and then source it from your other scripts. ⌘+T isn't a great default shortcut: it's what pretty much every application that has tabs uses to create a new one.

Alfred doesn't allow you to display remote images (i.e. give it a URL), not can it "lazy load" images. As a result, while it's possible to implement such a workflow, it would likely be clunky and slow to use because it will have to download all the images it wants to display before it can show any results. You could work around this by just displaying the URLs of the images in the results and using Alfred's preview feature (hit SHIFT on a result) to open a Quick Look window with the URL. That may or may not be a satisfactory solution.

Here is a demo workflow I wrote for someone that does exactly this, but based on an Excel spreadsheet. The code is extensively commented to explain what's going on. It's be easy enough to swap out the Excel bit for a database, but you didn't say what kind of database you're using. A Google sheet would be a terrible idea, as they're online only. It would make the workflow a lot slower and a lot more complicated to implement (you'd need to work with the Google APIs). It uses Alfred-Workflow's search algorithm, so you get partial matching, substring matching, initial letter matching etc. out of the box.

To find your scripts, your best bet is probably to set up a File Filter. Then to run it, you can use (something like) the following script in a Run Script action: script_path="{query}" script_dir=$(dirname "${script_path}") cd "${script_dir}" "${script_path}" Note: This script requires the executable bit to be set on the script you're trying to run. You can connect your File Filter directly to the Run Script action and/or use a File Action.

The 1Password data is at ~/Library/Application Support/1Password N/3rd Party Integration/bookmarks-default.json where ~ means your home directory (e.g. /Users/bob) and N is the 1Password version number. I've been using 1Password for a while, so my data is in a folder named 1Password 4 even though I'm now using version 6.

That's because the problem isn't with Alfred, it's with Filemaker. Alfred simply tells OS X to open the file(s) using the standard API. OS X then tells the relevant application to open the file(s). Any issue you're having is with that application, not OS X and not Alfred. The best you can do with Alfred is to try and work around the problem with Filemaker. If that doesn't work, it's still Filemaker causing the problem.

You can't search the contents of native Google Docs files because the files on your computer are simple JSON files that only contain links to the online version of the files. That is to say, the actual documents (and therefore the contents) simply aren't on your computer.

Yes, it does, or at least it does for me and should for everyone because tell application … starts the application if it isn't running.

Could you explain a bit more clearly what you're looking for?

FYI, 6 words is the minimum length you should use for a decently secure password. On a modern password-cracking box, the default length of 4 words can be cracked in under 3 minutes on average. 5 words is about 4.5 days. 6 words should hold out for 26 years. These numbers are based on an attacker using the exact same word list, which is not the likeliest scenario, but it's a fair bet that any dictionary-based attack will include all of these words. For anyone interested in the maths, you get log2(N) bits of entropy per word, where N is the number of words in the list. That's ~11 bits per word in this case. The average number of guesses needed to find the right password is 2n-1 where n is the total entropy in bits. The times assume 45bn guesses/second, which is what a modern dedicated password-cracking box (made of off-the-shelf parts) can do.

No, you didn't explicitly mention that it generates secure passwords. However, people tend to assume that password generators do generate secure passwords, at least by default. I mean, why would anyone want a program to generate passwords that aren't secure? Please feel free to edit your post and replace my rather stark warning with a more measured one.

Released v2.1.4 today. Add support for MS Outlook Add support for Airmail 2 Remove duplicates based on name and email address Self-update by entering @ workflow:update in Alfred, or download from GitHub or Packal.

This does not generate secure passwords. The defined pattern severely reduces the security of any generated password, and Python's random module is not suitable for generating cryptographically-secure passwords. It says so very clearly in the documentation.

Just stumbled across this. Two observations: random.org is not more secure. It may be in theory, but using a web service as a source of entropy is a terrible idea. It is relatively easy to subvert a webservice with versions of Python before 2.7.9, which do not verify SSL certificates. This means every pre-Yosemite OS X release. A web service is only acceptable as a source of entropy if you XOR the data with existing random data. Python's random module is not suitable for crypto purposes, i.e. generating passwords. It says so very clearly in the Python docs. As it also states there, use SystemRandom or os.urandom() for cryptographic purposes. I've added a note to your post to reflect the fact that these passwords are not secure. Please fix the issue.

Alfred's built-in Open URL action only supports one placeholder ({query}). If you want to insert multiple parameters into a URL, you'll have to write a script that parses {query} into the multiple parameters and inserts them into the URL. Then you pass the full URL to an Open URL action.

No, afraid not. Alfred doesn't work that way. There's one URL per result. You can send the URL to different actions by holding CMD/CTRL/ALT etc., but it's not inherently possible to change the URL by holding down a modifier, which is what you're requesting. You can work around that, but the workflow isn't set up that way. You would have to implement a separate I'm Feeling Lucky search in the workflow.

Alfred is better for opening URLs. 1Password's search shows everything, not just URLs, and it isn't very smart, i.e. it doesn't remember which result you chose for which query, like Alfred does. Also, a lot of people are just far more used to hitting that Alfred hotkey.

I understand the motivation, but given that Alfred's knowledge is stored in an sqlite database and it'd be relatively easy for someone determined enough to reverse engineer the behaviour sufficiently well, is it really worth hiding the details of how Alfred works from its users? I understand that Alfred's knowledge is "the clever bit", but ultimately, you do give that functionality away for free with the non-Powerpack version of Alfred. It's the workflow API that users have to pay for. In that regard, isn't that where Alfred's real value lies? Application launchers are plentiful. If someone took it upon themselves to create a competitor to Alfred, replicating the workflow ecosystem would be the hard part. Which, again, is what people buy the Powerpack (i.e. pay) for.

Been looking into this. It looks like it's a problem with OS X. Which version are you running? 10.11?

I have 2 hashed directories, which is also the number of Macs I have, so picking one at random/grabbing the first probably won't work. The localhash appears to be a SHA1 hash (they're 40 characters long). Only Andrew could tell you what it's a hash of, though. I tried hashing MAC addresses, but to no avail A hacky workaround I can think of would be to temporarily add a custom workflow to Alfred that extracts and saves the localhash of that machine at, say, ~/.alfred_localhash. You could then call it via AppleScript and delete the workflow again after it's run: tell application "Alfred 2" to search "savelocalhash" delay 0.2 tell application "System Events" to keystroke return (Assuming "savelocalhash" is the keyword for the workflow (or you could use an External Trigger).) Probably simpler to ask Andrew how the localhash is generated…

A workflow shouldn't be able to lock up Alfred, as they shouldn't get run till you type their keyword. Have you changed the workflow's keyword? Have you tried deleting and re-installing the workflow?

I just tried again on my main Mac. Alfred is finding Google contacts no problem now. Same software, same Google account. I've tried adding and removing accounts on both machines (they're synced via Keychain). It appears that fiddling with the configuration on my Yosemite machine "fixed" it on the El Cap one. There seems to be something wrong with contacts in El Cap: my machine is currently going berserk asking for the password for my CardDAV account, claiming it can't log in. I'm watching the server log, and AddressBook seems to have turned it into 2 accounts, 1 correct and 1 invisible and wrong. Weird.

Apple's telling porkies. Perhaps they just say that so they don't get grief when a new account type doesn't work. Note that Alfred works just fine with iCloud contacts, which technically aren't local either… I've just tested this on my MacBook Air, which is still running Yosemite, and Google contacts show up just fine with Alfred. This is the same Google account that didn't work on my other machine. Could it be an El Cap issue? WRT to using the AddressBook API, I'm just looping through all contacts and extracting the interesting data: ABAddressBook *AB = [ABAddressBook sharedAddressBook]; for (ABPerson *person in [AB people]) { … … } The actual implementation is in Python using the pyObjC bridge, but here's the proof-of-concept Objective-C program I made. I just tested it, and it dumps Google and Facebook contacts just fine. I'll test the program again on my El Cap machine when I get home.

Yeah, that put me off using the AddressBook API in MailTo initially, but when I gave it a try, it returned contacts from all these kinds of accounts (I could never figure out how to get my LDAP server to work with Contacts.app).

Enter / in Alfred (to start browsing the root filesystem). You may have to enter /a to get /Applications at the top of the list. Hit ⌥+↩ on /Applications to open it in Finder.