deanishe

It's like two or three extra lines of code to use SecureRandom instead and improve the security of the generated passwords. I appreciate and understand your attitude to workflows, but it's not a universal one. As a result, I think it's important that you mention that you don't consider your workflow appropriate for generating super-secure passwords. I also keep all my passwords in 1Password, but I wrote my own generator because I dislike the lack of transparency in 1Password's. There's no indication of how it calculates password strength, and the algorithm (exactly X digits and Y symbols) is a bit suspicious to me. Also, it doesn't support a super-useful technique for generating hard-to-crack passwords: non-ASCII characters. Throw a ü or ø into a password, and it is way more secure (most crackers only use ASCII).

I'm not sure how this is simpler to use than my password generator, but whatever. Unfortunately, your workflow uses Ruby's rand() function, which is not a good source of entropy, and therefore not very secure. You really should use SecureRandom instead, which uses /dev/urandom as a source of entropy (the best you'll get without having the user bang on the keyboard like a monkey). Indeed, a password generator should absolutely not rely on online services, or any other services not under the user's control. Asking a webpage to generate your passwords for you is a very bad idea (unless you know and trust the operator 100%).

property accountName : "iCloud" property folderName : "Notes" -- Return title and URL of current Safari page on getSafariPage() tell application "Safari" set theURL to URL of front document set theTitle to name of front document end tell return {link:theURL, title:theTitle} end getSafariPage -- Add note to Note.app -- the body of the note it theTitle + theText on addNote(theText, theTitle) set theBody to theTitle & return & theText tell application "Notes" tell account accountName set theNote to make new note at folder folderName with properties {body:theBody, name:theTitle} end tell end tell end addNote on run (argv) set pageInfo to my getSafariPage() my addNote(link of pageInfo, title of pageInfo) end run

If you're trying to run AppleScript, you need to set the language to AppleScript, which is indeed the "AS" in /usr/bin/osascript (AS). So, yeah, use that instead.

What is a "/bin/bash Apple Script"? That sounds like a problem.

When Alfred runs your workflow, it always does to from the workflow's own directory. That is to say, from any running workflow, the user's workflow directory is ../.

If you want to run a workflow script without Alfred's GUI, you shouldn't be running it via Alfred… Try calling the script directly. Also, the slowness is probably not due to Alfred. AppleScript is the more likely culprit.

No to both questions, I'm afraid. (1) is beyond the scope of the workflow. (2) Alfred already does that (but I prefer FastScripts).

It's already in there. Please refer to the documentation.

This script gets the URL of the current Safari page and creates a new note in Notes.app containing the URL. Put it in a Run Script action with Language = /usr/bin/osascript (AS), the attach it to a Keyword/Hotkey of your choice. property accountName : "iCloud" property folderName : "Notes" on getSafariUrl() tell application "Safari" to return URL of front document end getSafariUrl on addNote(theText, theTitle) tell application "Notes" tell account accountName set theNote to make new note at folder folderName with properties {body:theText, name:theTitle} end tell end tell end addNote on run (argv) set theUrl to my getSafariUrl() my addNote(theUrl, "URL from Safari") end run

AFAIK, there isn't a workflow to do this. There doesn't appear to be an API, either, to pull search results from. There is a JSON API for search suggestions, which might be acceptable to you (where cellfun is the search query): http://uk.mathworks.com/help/search/json/doccenter/en/R2015b?submitsearch=&qdoc=cellfun If those results are helpful, this tutorial for Python workflows might help you turn them into a workflow.

cURL write its output to STDOUT by default. It's possible that its output is interfering with the notification (e.g. Alfred registers a blank line and ignores it.) Try redirecting cURL's output: curl ... > /dev/null.

Sweet. I think fully-encoded URLs is the only proper thing to do because unencoded URLs are technically invalid and will likely not work in many contexts, e.g. you can't put a URL containing single quotes into href='...'. Seeing as there are already loads of partially-encoded URLs in the wild, I imagine Alfred will still need to do some processing of the URLs to avoid any double encoding.

I've been poking a stick at it. The URL-handling subsystem doesn't touch URLs that are fully URL-encoded, but does encode URLs that aren't URL-encoded or are only partially URL-encoded. The latter is what's happening here. The unencoded URL for my Linguee Custom Websearch is: alfred://customsearch/Search linguee.com for '{query}'/l/ascii/noplus/http://www.linguee.com/deutsch-englisch/search?sourceoverride=none&source=auto&query={query} The fully-encoded URL is: alfred://customsearch/Search%20linguee.com%20for%20%27%7Bquery%7D%27/l/ascii/noplus/http%3A//www.linguee.com/deutsch-englisch/search%3Fsourceoverride%3Dnone%26source%3Dauto%26query%3D%7Bquery%7DAlfred handles both these URLs correctly, whether pasted in Alfred or passed to open (Safari treats the unescaped URL as a search query, presumably due to the spaces). However, the URL Alfred exports is only partially encoded: alfred://customsearch/Search%20linguee.com%20for%20%27%7Bquery%7D%27/l/ascii/noplus/http://www.linguee.com/deutsch-englisch/search?sourceoverride=none&source=auto&query={query} As a result, the OS X URL-handling subsystem encodes the URL, producing something that's half properly encoded and half double encoded (in terms of the desired result): alfred://customsearch/Search%2520linguee.com%2520for%2520%2527%257Bquery%257D%2527/l/ascii/noplus/http%3A//www.linguee.com/deutsch-englisch/search%3Fsourceoverride%3Dnone%26source%3Dauto%26query%3D%7Bquery%7DThus, there isn't a problem with Alfred's handling of URLs, but rather the bug is that the exported URLs (for Custom Searches) aren't fully URL-encoded in the first place. I guess it works properly with Safari because that has more robust handling of not-quite-right URLs.

So, Alfred is "double" URL-encoding the URL and then passing it to the system? Does that use a different mechanism than open? Because open also doesn't work correctly with URL-encoded alfred:// URLs.

The problem might be that recent versions of Alfred use a different focus mode. Try changing the Focusing in Alfred Preferences > Appearance > Options to Compatibility Mode. That will make Alfred take focus the old-fashioned way.

It's because your question is a strange one. There's a key for \ on your keyboard, so why would you want a hotkey that does the same as a physical key? To answer your question, a faster way to do it that doesn't mess with the clipboard is: tell application "System Events" to keystroke "\\"

It is possible to differentiate between left and right ALT keys (or CMD etc.), but I don't think Alfred does (same as most apps). Generally, it's not a good idea to use ALT for global shortcuts with text input keys (i.e. non-function keys). The reason is that it causes the problem you're having. ALT and SHIFT are used to enter text, so if you use them for shortcuts, you're likely to find yourself firing a shortcut when you want to enter a character or entering a character when you want to use a shortcut. Therefore it's a good idea to always combine ALT and/or SHIFT with CMD and/or CTRL when defining shortcuts that you might use when a text field is selected (which includes global shortcuts like the one to activate Alfred).

I'm at a bit of a loss, to be honest. My workflows usually explicitly specify /usr/bin/python, and you say they work with that Python when run from a shell… I'm fairly certain that it's an issue with your system, rather than the workflow(s)/library, simply because nobody's had this problem before. Is there anything in the workflows' log files (use <keyword> workflow:openlog in Alfred)? Is there anything in the syslog in Console.app? Have you messed around with your launchd/system environment? Have you tried rebooting and/or repair permissions?

Okay, that's pretty weird. I cant imagine what "stupid" thing you might be doing. First, we need to figure out if it's a problem with the workflow, the workflow library or your system. Which version of OS X are you using? Do any other Python workflows work that aren't written by me or based on my Alfred-Workflow library? Could you try running the script manually from the workflow directory using /usr/bin/python (instead of just python)?

No probs. FWIW, you can also use JavaScript in Alfred scripts with the language /usr/bin/osascript (JS) Also, while STDOUT becomes the next action's input, STDERR is captured in Alfred's workflow debugger. Very useful.

FWIW, as long as something is set for arg or copytext in wf.add_item(), you can hit ⌘+C on an Alfred result to copy it to the clipboard (i.e. you don't need valid=True if that makes no sense otherwise). By preference, copytext will by copied to the clipboard. If copytext isn't set, arg will be copied instead.

That's exactly how Alfred works. It just uses {query} throughout (rather than {input} and {output}). As far as running scripts is concerned, any output to STDOUT is treated as the input to the following action (i.e. the following action's {query}). The exceptions are Run NSAppleScript (where you use q for input and return for output as described above) and Script Filters, which must output XML to STDOUT.

I think you've misunderstood how workflows work. Curly braces only work with {query}. It has nothing to do with variables: it's a simple text placeholder. When Alfred runs your script it does a simple search/replace and replaces any instance of {query} with the value of your input. Wrapping anything else in curly braces just gives you a word in curly braces. Input to a script or notification is always inserted via {query}. The names of your variables are entirely irrelevant. The exception is the Run NSAppleScript action you're using. Because this is run as live code within Alfred, it can pass a real variable to your code, instead of replacing the text {query}. That's the q in on alfred_script(q). Try this:

Doesn't adding return script_output to your script work?