deanishe

I just use: tell application "Finder" make new Finder window to home activate end tell That will always open a new window on the current desktop. I have it linked to an Alfred hotkey. May I also suggest DragonDrop. It's extremely handy for dragging and dropping, as the name suggests. You start the drag, wiggle the mouse a bit, DragonDrop pops up, you drop the files in there, and then go off to find your destination for the drop. Very handy.

Asking for Finder's selection will return an "application file" object, "folder" object or "document file" object (or a combination), depending on what's selected. Alfred gives your script a "text" object (i.e. the POSIX path to the selected app). You have to turn that "text" object into an "application file" object to grab its id. Using NSAppleScript: on alfred_script(q) set theFile to POSIX file q tell application "Finder" set theApp to application file theFile set theId to id of theApp display dialog "ID of application " & theApp & " : " & theId end tell end alfred_script Having to change object classes all the time is one of the things I dislike most about AppleScript, and there are a lot of things I dislike about it … It's a good habit to log the objects you're working with so you know what kind of objects they are. In AppleScript Editor, just do log theObject, and it will show up in the Events/Replies pane at the bottom.

Did you figure this out? As best I can tell, Alfred would only send one filepath to the script.

I wouldn't describe it as an error per se. Just something that's worth mentioning in the README as a potential cause for a script not working properly with non-ASCII filepaths if they aren't also normalised the same way. If you call os.listdir(u'/unicode/path'), the returned filenames will be NFD-normalised. So it might be a good idea to mention that decode is altering Alfred's input in such a way that filepaths won't necessarily match those your script gets from the filesystem. That's a good point regarding .git. I hadn't thought of that as I build my workflows with a script that ignores .git.

<title><riki12> TC: 79GB available</title> <icon type="fileicon">/Volumes/<riki12> TC</icon> If that's what's coming out of the script, that's what's breaking Alfred. It doesn't like the < and > in the volume name, as it's invalid XML. This might fix the problem: #/bin/bash list=$(df -H) IFS=$'\n' echo '<?xml version="1.0"?><items>' for item in $list do if [[ $item == /* ]]; then #name dev=$(echo $item | awk '{print $1}') path=$(echo $item | awk '{$1=$2=$3=$4=$5=$6=$7=$8=""; print $0}' | sed -e 's/^ *//g' -e 's/ *$//g') name=$path # echo "path : $path, dev : $dev" if [ "$path" == "/" ]; then name="$(diskutil info $dev | sed -nE 's/^ *Volume Name: +([^ ].*) *$/\1/p')" else name="${path##*/}" fi # echo "name : $name" # path=$(echo $item | awk '{print $1}') size=$(echo $item | awk '{print $2}') used=$(echo $item | awk '{print $3}') free=$(echo $item | awk '{print $4}') perc=$(echo $item | awk '{print $5}') free="${free/T/TB}" free="${free/G/GB}" free="${free/M/MB}" free="${free/K/KB}" echo '<item uid="diskspace" arg="" valid="no"> <title><![CDATA['$name': '$free' available]]></title> <subtitle>'$used'B ('$perc') used of '$size'B total</subtitle> <icon type="fileicon"><![CDATA['$path']]></icon> </item>' fi done echo "</items>"

I'm afraid I can't help you with no information. Can you copy the script into its own file, run it in Terminal and post the error message you get?

Yes, that's the way Alp's set up, but that's not immediately obvious and I'd argue Your First Alfred Library should probably be something simpler unless you need some of Alp's (very cool) features.

I'll be perfectly honest, no. I don't use alp myself (I just thought I'd have a peek, having fixed a similar problem with nikipore's alfred.py), and thought I'd give you a heads-up on a potential problem. I'd rather not take any responsibility, even indirectly, for a lib I don't use. The way I see it, if I'm the first person to mention this—and I don't even use alp—it's only a potential problem, not a real one, so changing it might cause more trouble than leaving it as it is. At most, I'd mention the potential problem in the README (there are valid arguments for both NFC and NFD normalisation). That said, would you mind if I borrowed a couple of alp's modules for my own alfred library I'm considering building? I want something much more lightweight than alp (no bundling of stuff like requests and particularly no importing of everything in __init__.py), but I really like the look of your keychain module especially. It'd all be on GitHub. I'm aiming at something that can easily be added to a workflow as a git submodule for easy updating. If you're alright with my borrowing a module or two, I'll update the README to mention the potential problem with filenames. How's that sound?

Hi Phyllisstein, I just wanted to point out that the NFC normalisation alp uses in alp.core.decode won't match data returned by Python's filesystem libraries (OS X uses NFD normalisation—more or less). Data passed as script arguments by Alfred will also be NFD-normalised, but I figure that's primarily what the decode function is aimed at. I've no idea whether strings returned by filesystem libraries (NFD) are more important than string literals in Python code, but I thought it worth mentioning that there's a bug waiting to happen here. A filepath with ü in it returned by os.listdir, for example, won't match unicode literals in the code or input from Alfred (if it's been NFC-normalised, as is alp's default). Using NFC normalisation (Python's default), ü is \xfc, using NFD, it's u\u0308. These will not match using ==. Oddly, ü inserted into a script via "{query}" will be u\xcc\x88…

You're welcome. Here's the Python Unicode tutorial, but the golden rule is decode on input, encode on output. You should always test your scripts with non-ASCII input to flush out any errors. Most of the Alfred libraries are overkill for a simple script like this one, but you might give nikipore's one a try. It's nice and lightweight (just one file), and does a good job with encoding. Alp, by contrast, is very bloated (and therefore slow) and does not do encoding correctly (wrong normalisation for OS X).

The output escaping isn't the problem—he's letting the XML library do that, as would any Alfred library. The big problem is the text encoding is all over the place. Veritas, you're mixing unicode strings (string_to_regex) and UTF-8-encoded strings (everything else). You must encode the output to UTF-8 before printing it to Alfred. Try this instead: # -*- coding: utf-8 -*- import sys from xml.etree.ElementTree import Element, SubElement, Comment, tostring string_to_regex = sys.argv[1].decode(u'utf-8') regexified = [] # Builds each part of the XML tree def build_xmltree(items): item = SubElement(items, u'item') title = SubElement(item, u'title') subtitle = SubElement(item, u'subtitle') icon = SubElement(item, u'icon') return (item, title, subtitle, icon) for i in string_to_regex: if i in u"\\[]().*+-^$|": regexified.append(u"\\" + i) else: regexified.append(i) alfred = u''.join(regexified) items = Element(u'items') item, title, subtitle, icon = build_xmltree(items) item.set(u'uid', u'regexified') item.set(u'arg', alfred) item.set(u'valid', u'yes') title.text = alfred subtitle.text = u'Copy to Clipboard' print tostring(items, encoding=u'utf-8') And set up the script escaping so: It should do what you want (if I've understood it correctly). A lot of the strings I've changed to unicode literals are unnecessary (tag names, 'utf-8' etc.), but it's a good habit to get into with Python 2, otherwise at some point you'll combine unicode and non-unicode and bad things will happen. Be sure to decode all external input (sys.argv, os.environ, sys.stdin etc.) to unicode immediately, and encode all output (usually to UTF-8) before you print/write it. If you don't do that, any non-ASCII character will likely break your script. If you're working with filepaths, you also have to call unicodedata.normalize(u'NFD', u'your unicode path here') or weird things will happen (on OS X).

The workflow is throwing an error for me. #<NoMethodError: undefined method `[]' for nil:NilClass> /Volumes/Users/XXX/Dropbox/Config/Alfred 2/Alfred.alfredpreferences/workflows/user.workflow.C1317428-1511-401C-A41B-FE46B52EC364/transmit.rb:65:in `block in cache_xml' I did a bit of debugging, and it's choking on an open access FTP site that has no username. The error is caused by: 'username' => fav['attribute'].detect { |attr| attr['name'] == 'username' }['content'] I'm not familiar enough with Ruby to fix the error, but the workflow shouldn't assume favourites have usernames because they don't always require them.

If you replace the script filter contents with the following, it should do what you want: list=$(df -H) IFS=$'\n' echo '<?xml version="1.0"?><items>' for item in $list do if [[ $item == /* ]]; then #name dev=$(echo $item | awk '{print $1}') path=$(echo $item | awk '{$1=$2=$3=$4=$5=$6=$7=$8=""; print $0}' | sed -e 's/^ *//g' -e 's/ *$//g') name=$path # echo "path : $path, dev : $dev" if [ "$path" == "/" ]; then name="$(diskutil info $dev | sed -nE 's/^ *Volume Name: +([^ ].*) *$/\1/p')" else name="${path##*/}" fi # echo "name : $name" # path=$(echo $item | awk '{print $1}') size=$(echo $item | awk '{print $2}') used=$(echo $item | awk '{print $3}') free=$(echo $item | awk '{print $4}') perc=$(echo $item | awk '{print $5}') free="${free/T/TB}" free="${free/G/GB}" free="${free/M/MB}" free="${free/K/KB}" echo '<item uid="diskspace" arg="" valid="no"> <title>'$name': '$free' available</title> <subtitle>'$used'B ('$perc') used of '$size'B total</subtitle> <icon type="fileicon">'$path'</icon> </item>' fi done echo "</items>"

Excellent! Thanks, Andrew.

Right. I did misunderstand you I just wanted to know if Alfred would only report the DivideByZero or would show the whole traceback.

Great workflow! My only wish is that the API provided gender info for us non-native speakers. Duden.de doesn't provide an API. Heck of a lot more work involved in creating a workflow for it, and a good chance Duden would block it.

Had a poke around, and it looks like exporting the plist as XML, not JSON, should fix the problem. I'll try and get that changed tomorrow (well, later today, I guess) and upload a new version. Thanks for the testing and explicit error message. It was very helpful.

You have it? Hot damn! I want it! (Well, I want it to give to the users for whom my workflow isn't working and I can't debug the problem). Any chance you could whip up a quick Python script filter and see what the output of the following is: def f1(): 1 / 0 def f2(): f1() def f3(): f2() def f4(): f3() f4()

Thanks, Tyler! Hadn't seen that. To be honest, I'm not overly comforted by the screenshot. Do you know if it shows the full output of a script error? For example, a Python traceback looks like this: Traceback (most recent call last): File "smartfolders.py", line 280, in <module> sys.exit(main()) File "smartfolders.py", line 270, in main results = search_folders(query) File "smartfolders.py", line 214, in search_folders folders = get_smart_folders() File "smartfolders.py", line 98, in get_smart_folders oops NameError: global name 'oops' is not defined Just showing the last line, as Automator does, for example, is not very helpful. This is an obviously contrived example (I just typed "oops" on a random line in the script), but nevertheless, the really helpful information is not contained in the last line.

All my upvotes for some form of workflow debugging feedback. I understand this is in the works, but I know nothing about the scope of the feedback. IMO, in order to be useful, it must provide Precise details of why Alfred rejected a workflow's results if it did exit cleanly, i.e. not simply "bad XML" (which is, by simple fact of the failure, kinda obvious) but an actionable error report and the line & character that caused the error. Any output generated by the workflow (on stdout and stderr) if the workflow doesn't exit cleanly. It would be very nice if Alfred provided, in the case of a workflow error The environmental variables The precise input sent to the workflow These are all common sources of errors when adding scripts to apps like Automator, Hazel and Alfred. Both Automator and Hazel report errors, but neither provides sufficient information to debug them easily. The last 3 can usually be worked around by the script author, the first cannot. Personally, I'd be more than happy if Alfred simply provided a log file containing the above information. Anything else in unnecessary.

However, there's no reason why Alfred couldn't allow workflows to output <action> items as well as <item>, err, items. That way, workflows could provide custom actions for their own items. Alfred need know nothing about the nature of the items, just pass along their respective args to the workflow-specified actions. That would allow workflows that work with very different data types to integrate seamlessly with Alfred, even if Alfred doesn't understand the data they're using at all.

How would that work? I mean, where do workflows get the contact information from? They'd have to be able to talk to the Contacts database. Or do you mean workflows can spit out a name/email address, and Alfred should find the corresponding contact itself?

This is a very cool idea. I think 30 ms is much too short of a delay, however (that's 30+ characters per second!). The optimal delay would be very user and workflow dependent. Some users type much faster than others; some workflows take much longer to return results than others. And the response time of the same workflow can be highly variable, depending on the state of what the workflow is leveraging (other apps, the OS, the network). I think a decent compromise would be for workflows to be able to indicate a suggested minimum query length/change in query length (i.e. don't query with less than 3 characters or if fewer than 2 characters have been added/deleted), which would be honoured by Alfred until a timeout has been exceeded. The timeout would be decided by Alfred based on observed user input speed (i.e. Alfred might call the workflow after 250 ms for a touch-typist like me or after 500 ms for a hunt-and-pecker like my dad), or a user-specified value.

I got bitten by a similar mistake (which Kopischke also found—and fixed). I was building Spotlight queries such as kind:Movies. In this case, there's usually a universal alternative of the com.apple.whatever form. Also, isn't it possible to "click" menu items by index instead of name? Obviously not a universal solution, but a whole lot simpler than the alternative in cases where it's possible.

Thanks for the speedy response Andrew. Encoding issues was my first thought, too, but I'm confident I've excluded that possibility. As noted, the XML consists only of ASCII characters. I'm 99.9% certain it isn't an encoding problem on my end. I had the users capture the output in files via shell redirection, zip 'em (to avoid the content getting encoded/decoded) and send them to me. I wrote a workflow to cat the file contents to my Alfred, and it works perfectly. I work with a lot of German text and files, so the workflow has been thoroughly tested with non-ASCII input and output. All input is properly decoded to Unicode and NFD-normalised, the XML output is UTF-8 encoded before it's sent to Alfred (and it's all encoded at once, to ensure no mixed encodings). Please feel free to check the code. I still suspect it does have something to do with text encoding, but between the workflow and Alfred on systems with some non-standard configuration. Unfortunately, with zero feedback from Alfred, I felt my only remaining option was to ask you (I want my workflows to work for everyone), as you're the only person with access to concrete information on why workflows fail in Alfred, but work on the CLI. Consequently, I'm extremely pleased to hear that a debugger is coming. Will it also show error messages from internal workflow errors (i.e. the stderr output)? I dearly hope so. Scriptable apps (such as Automator and Alfred) that don't provide that information are difficult to develop for.