rice.shawn

To keep Packal a bit more open, I used Github as a backend. Github restricts (unless they changed this) unknown filetypes to 10mbs. And, even though `alfredworkflow` files are `zip`, they are still technically unknown.

Is it that the XML is bad because there isn't an appropriate bit of data that is escaped with CDATA?

I'm through and through American. I spent the first many years in Texas and the last decade in New York. But before I had to come into an office, my natural hours didn't quite match up to my timezone. The job has definitely got me working quite a bit with much less downtime to work on my other projects (last weekend, I had to work 28 hours to save a project that was moving past deadline), but I guess this is what I get for working at a publishing company with editorial deadlines. I've been making an effort to carve out time to work on Packal, but a lot the Alfred 3 changes have made it harder to support both Alfred 2 and Alfred 3. I don't want to ditch those still using Alfred 2. Packal still gets about 18k page views a week and has some value as a central place for workflows, so I do want to repair it. So little time...

Sometimes it is near 16 hours a day. It's not quite dead yet.

I just (finally) pushed an update that should make this work out of the box with Alfred 3 as well as 2. Find the update on Packal, and let me know if there are any problems.

To follow up, if you are writing it in Python and using Dean's library, he's made some nice wrappers around these commands for ease. If you're writing it in PHP and using Alphred, then the same sort of wrappers exist. If you're doing it otherwise, then you'll have to access the commands yourself.

Crap. So I need to get back to work (deadline tomorrow; needing to do crap over the weekend). And I didn't manage to refresh my AS quick enough to fix the AS in the configure script. I'll get back to that after I push the final changes on the work deadline. For now, I pushed some changes to the git repo; but I need to get on an old computer with Alfred 2 in order to export it and not break others' installations. Will do that and post here after I fix the AS problem.

As Andrew mentioned, among other things, Packal.org runs a virus scan on every workflow uploaded (using clamscan, and the virus database is updated daily), so I can assure you that there are no viruses in any workflow that clamscan can catch (early on I did test by uploading workflows with viruses, and Packal rejected them). That being said, there can still be malicious activity, but I haven't seen any workflow that has done anything bad since Alfred 2 has been out. By bad, I mean intentionally bad. The problems that Dean mentioned have happened, but the community is pretty good about finding these and then reporting them and getting them changed. S

Actually, caffeinate can do this. You just need to have the "emulate user activity" option selected.

The AS just runs a quick pop-up for the configuration, so that problem does not apply. There is no tell Alfred 2 or Alfred 3 in there (unless I'm totally forgetting something from code that I wrote three years ago -- total possibility). (Although you could get around that problem by checking to see if they are installed, and wrapping the tell statements in an if, etc...)

That's exactly what I'm debugging right now... trying to get the system variable and convert it to a path in AS. Damn, it's been a while since I've touched AS.

Damn. Just report these bugs to me, and I'll take care of them. This is an insanely old workflow that existed before the environmental variables were introduced, so I had to hardcode the paths. I'll update them.

I just did a quick fix. It might be working again.

Yep. I figured that's what it was. Amazing that this particular escaping issue hasn't come up until now, especially since it's been there since Sept 15.