nikipore

@clenden

 

I'd suggest to drill into the cause of your problem by debugging intermediary results with either one of the two methods:

• print statements (only works on the command line)
• writing to a temporary file (see above how to do that)

The most likely cause I can think of is that the places.sqlite you are scanning is not the one associated to the Firefox profile you are actually using. What FF version are you on, btw?

I'd suggest to use a fixed path like ~/Library/Application Support/Alfred2/Workflow Data/Python/python to point to the Python interpreter of your choice. This can be as simple as a softlink. And I would recommend to everyone to use a virtualenv install which is standard and lightweight. No need to install another Python, just re-use whatever Python you are using (system, MacPorts, brew, ...).

The query was implemented such that it matches any string where the letters m-a-m-e appear in this order. I now changed this to words (separated by space). I pushed the new package to github. Feel free to give it a test drive.

Please replace the icon method as shown below. This should catch your error. Please let me know if that helps; I will commit that patch to git, then.

def icon(db, faviconid):
    if not faviconid:
        return
    data = db.execute(u'select data from moz_favicons where id=%d' % faviconid).fetchone()
    if not data:
        return
    icon = os.path.join(_CACHE, 'icon-%d.png' % faviconid)
    if (not os.path.exists(icon)) or ((time.time() - os.path.getmtime(icon)) > _CACHE_EXPIRY):
        open(icon, 'wb').write(data[0])
    return icon

Would you please temporarily replace the last block by the code below (the second and third lines have been inserted) and check /tmp/alfred.txt whether your places.sqlite file is identified correctly and exists?
 

(profile, query) = alfred.args()
import os
open('/tmp/alfred.txt', 'w').write('profile=%s\nplaces=%s\nexists=%s' % (profile, places(profile), os.access(places(profile), os.R_OK)))
db = sqlite3.connect(places(profile))
alfred.write(alfred.xml(results(db, query), maxresults=_MAX_RESULTS))

Mike,

sorry for answering half a year later, but this forum's amazing activity in the birth phase of Alfred 2 workflows was just too much for me to follow, so I kind of pulled the plug. I'm on Mountain Lion too (10.8.5), and the workflow still works perfectly for me on FF 24. Are other Python workflows functioning? Where is your places.sqlite?

Cheers,

Jan

Thanks for the suggestion. I'll look into that when I find the time (which could take a couple of weeks).

 

EDIT I just uploaded a modified version which should work for both SIP addresses and normal phone numbers. It replaces a leading + in phone numbers by the country prefix. It is preconfigured to the most common (pretty much everyone but U.S.) setting 00 and can be changed in the bash script.

I suggest to introduce a "streaming" mode which sets up the communication Alfred <-> subprocess via stdin and stdout of the subprocess. It would be optimal if the encoding was specified explicitly, I propose normalized UTF-8 (not Mac UTF-8). Since the stdout route subprocess -(stdout)-> Alfred is already there, this would symmetrize the communication.

I've filed a feature request here. Not quite sure what you mean by the streaming mode. It is possible to run command line stuff using NSTask, where parameters aren't interpreted in any way at all. So if {query} was one of the parameters, there would be no need for escaping. However, it is a little harder to use and I'm not sure how to provide a good interface to allow that. But it shouldn't be necessary once proper escaping is implemented.

Thanks for the feature request. Not quite sure whether it's really possible to pass every conceivable string as a command-line parameter. By "streaming" I mean that Alfred could feed {query} on the stdin of the subprocess; streaming via stdout is the way the communication from the subprocess into Alfred is set up already. I'll maybe add the streaming part as an alternative suggestion to your feature request.

In Python, the communication on behalf on the subprocess would look as follows:

query = sys.stdin.read()

Up to decoding and normalizing the binary stream (which could then even be encoded as properly normalized UTF-8), that would be the whole story. Clean and easy, no escaping needed at all.

This one's for you: http://www.alfredforum.com/topic/836-firefox-bookmarks-and-input-history/

@johnjddoe: I can confirm that 2n-1 and 2n backslashes (n>0) within double quotes arrive in Python as n backslashes. Annoying indeed. I think we should file an issue to request a proper unescaping (if possible at all). Maybe the cleanest way out is to offer a streaming mode where the script harvests UTF-8 (either Mac style or normalized) on stdin and yields UTF-8 on stdout.

So as far as I can tell, there is no way to currently properly handle all user input (at least not easily). The best compromise I can see is using double quotes, and escaping only backquotes, double quotes and dollar signs. This should handle everything except backslashes.

I escape backlashes in Alfred and unescape them in python-alfred, and that approach also treats backslashes correctly. Which characters or character sequences are left which aren't treated correctly?

{query} should NOT have quotes around it, i.e. use

python script.py {query} 

with all the escaping ticked. This works perfectly even when the query contains spaces and quotes. Can you give me any examples where this doesn't work?

 

Sure: Just use a single quote '. That doesn't even trigger the Python script without double quotes around {query}.

 

 

In my experience, guys, it makes sense to be agnostic about the use of quotation marks around {query} and how much escaping you want; there's no best practice to dictate what you "should" or "shouldn't" do.

Disagreed. I think the best practice is to take care that any string arrives in Python just as the user entered it in Alfred (straight from the horse's mouth). If you've got that worked out, you wouldn't want to change that any more. Of course, you're free to interpret that string at will and as it suits your specific application.

Awesome, Robin. More of these, please!

I poked a bit more at the various options and can confirm once more that leaving the double quotes away is a bad idea. But the world isn't as simple as neither of us thought: Actually, the correct implementation seems to be to tick all escape options, use /bin/bash, escape the {query} with double quotes:

python yourscript.py "{query}" arg2 arg3 ...

and then unescape semicolon, round brackets, and space in the code. This at least works for all characters which Alfred offers to escape to begin with. I didn't test (and I'm not very interested in, because I lose testabiity that way) inline Python code.

I understand the way that escaping and arguments work. I think the hope there, and with string normalization, is to make alp behave a little better when there are special characters thrown into the mix, as I've been advised will happen with one of my own workflows. I'm not sure that it's the best technique, and I haven't done much testing yet, but it's a tilt at the ole windmill. The other element of the logic is that I'd like to reduce the amount of docs-Googling brand-new workflow developers have to engage in. Thanks for the reminder about changing the repo name.

 

Again, it eliminates the need to search the docs for the right formatting codes, which I can personally never remember, and standardizes the way timestamps are used as UIDs for the benefit of Alfred's sorting mechanism. Most of the module boils down to things that anyone could do on his or her own—in fact, all of it does; there's nothing totally "new" in here, as far as I can tell, just a collection of useful "old" tasks made simpler. E.g., yes, anyone could write the ctypes interface to the Keychain functions; the point is that now no one has to.

And no one did so far to the best of my knowledge. One more nit-picking thing: Python classes are usually written uppercase.

Hi! I'm just a workflow developer excited by all these cool new libraries. I have some questions about alp:

 

What is `alp.args()` for? Alfred by default escapes everything for you, so you can just use `sys.argv[1]`. Shell escaping is very poorly understood by most people, so perhaps I should explain more clearly:

In Alfred, run your python script, for example, by using language `/bin/bash`, and run your script with `python myscript.py {query}`. Note that there are no quotes around `{query}`. Make sure everything is ticked under the Escaping section. Then, in your script, `sys.argv[1]` will contain the exact arguments that the user passed to your script.

 

Also, what is `alp.decode(s)` for? I read the Python docs, but I'm not sure why you would need to normalize UTF-8 strings.

 

Finally, you should probably change the Github repo name to alp. Nice name, BTW.

 

Both, unescaping and decoding were features I introduced in python-alfred and which Daniel pulled trusting in my Python skills (and I do understand shell escaping as well, just didn't test it thoroughly enough). I've now tested that you don't need to (and hence shouldn't, so I'll remove that feature from alfred-python) unescape sys.argv when calling a Python script from the command line (choose /bin/bash and tick all escape options) via

python script.py "{query}"

and not, as you write, without the quotation marks. As to decoding, you definitely should move from UTF-8 to unicode to have an internally consistent handling of characters, and you should use u'string' literals throughout, and finally encode everything to UTF-8 again. The normalizing is necessary if you try and feed Python such strange things as my surname (Müller). The ü will end up basically as a UTF-8 version of the points followed by a u which is a Mac OS X thing and by no means a representation Python understands without normalizing.

 

I agree on your opinion about putting a lot of Alfred unrelated things into alp.py, and I still hope that Daniel moves that stuff into a module (or, better, package) of its own, but I see his point of setting the hurdle for script kids as low as possible.

 

Jan

Fixed it. You weren't testing for non-existing files (I don't have an ssh_config). Couldn't resist to clean up your Linter warnings. Hope I didn't break anything. Thanks for your contribution to python-alfred!

 

http://d.pr/f/jBYw

Mine is broken, too (all but 'com' should yield results with me). I cannot dig into it myself at the moment, gotta leave. Will do it tonight, if the problem is still there, then.

~/Archive/ssh$ python
Python 2.7.1 (r271:86832, Jul 31 2011, 19:30:53)
[GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from alfredssh import complete
>>> complete('com')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "alfredssh.py", line 122, in complete
    hosts.update(fetch_ssh_config('~/.ssh/config'))
  File "alfredssh.py", line 23, in update
    (hosts, source) = _list
TypeError: 'NoneType' object is not iterable
>>> complete('mac')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "alfredssh.py", line 122, in complete
    hosts.update(fetch_ssh_config('~/.ssh/config'))
  File "alfredssh.py", line 23, in update
    (hosts, source) = _list
TypeError: 'NoneType' object is not iterable
>>> complete('net')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "alfredssh.py", line 122, in complete
    hosts.update(fetch_ssh_config('~/.ssh/config'))
  File "alfredssh.py", line 23, in update
    (hosts, source) = _list
TypeError: 'NoneType' object is not iterable

 

phyllisstein,

 

I've played a little bit with your workflow and boiled it down to a plain vanilla Alfred thing plus a trivial bash script which also addresses AMeijer's question (he actually wanted Alfred to select things him, I suppose).

 

Best,

Jan

I really love mattlatmatt's Old Book theme for its reference to the typographic red/black style. I pay my respect to Matt by citing his interpretation first (what a head start!):

 

 

A very few things I did change though:

• I don't like to mix fonts, so I had to take a single Font.
• I like it readable, so that font should be sans-serif. I chose to use Helvetica. I'd love to spend my life looking at Futura >100 times a day, cf. Pedros minimal theme. But I've got to get some work done, and Futura is not nearly as readable (save maybe the original one ;-)
• I like these red numbers so much that I made them bigger (more readable, lets me navigate to results faster, and removes the sterility which Helvetica carries along).
• I added a slight level of transparency and tuned brightness a little bit away from white. It looks like milky glass, so cool!
• A hint: Turn on Andrew's blurry hack.

Wanted to share it before, but I only today learned how to embed screenshots via Droplr. So here it is, New Book:

 

Debugged it and found the reason: Due to a hotkey conflict, the action wasn't triggered at all. Everything works perfectly now. Thanks!

Nice one. Thanks for the +.png hint (was banging my head against the wall how everyone gets screenshots into their posts).

No, it doesn't. The two "-bash" test case still fails.

Hi,

 

a simple one, but nevertheless quite useful for me: a contact action to associate phone numbers with VoIP URLs.

 

It's on GitHub.

 

You have to associate the contact action yourself in the Alfred Preferences as shown below:

 

 

There is also a keyword call (If I see that people are using it, I might consider to add a script action which filters phone numbers):

 

 

It works very nicely with Telephone.app and X-Lite (for the latter, you have to change the URL to sip:{query}). Telephone.app sometimes doesn't react properly, but that's usually only when it's not running when the URL is being called.

 

Have fun!