UTF-8 is not a valid value for LC_CTYPE flag; exception in Python workflows [Fixed 2.7.1 b387]

[ipaterson]

Any python workflow using locale.getdefaultlocale() will crash in Alfred 2.7 due to an unhandled exception. Since the python docs do not suggest that it is even possible for an exception to be thrown from that function, I do not imagine anyone wrapped this in a try block.

 

I received some bug reports this weekend from some pre-release path folks who were seeing errors about unknown locale: UTF-8. I noticed in the release notes for the latest Alfred that the following change was made:

• Add LC_CTYPE=UTF-8 encoding to script environment

 

However, UTF-8 is not a valid value for this flag. Is this something that can be reverted or is there some case where it actually works? As a temporary workaround I was able to redefine LC_CTYPE in each of the bash scripts in the workflow, but hopefully that should not be necessary going forward.

export LC_CTYPE="$(defaults read -g AppleLocale).UTF-8"

 

Download a simple workflow that tests this bug. Type lcctype in alfred then action the result – it should show your current locale in large type but will instead fail with an exception.

Edited April 14, 2015 by ipaterson

[Andrew]

Hmm this is off the back of this post: http://www.alfredforum.com/topic/5582-sensible-defaults-or-a-clear-explanation-of-escaping-options/?p=34485

 

I'll look into this today and get a fix out!

[Andrew]

I've just popped out 2.7.1 which reverts the LC_CTYPE change - would you mind updating and trying this out? I'm keen to close this issue!

 

Cheers,

Andrew

[ipaterson]

Well done, in 2.7.1 the workflow is working again. I will follow up on the original discussion with some further thoughts.

[Andrew]

Well done, in 2.7.1 the workflow is working again. I will follow up on the original discussion with some further thoughts.

 

Perfect, thanks for the feedback