Hi,
sorry if my question is a bit off topic but I couldn't find any information.
I'm just writing a tiny perl script which converts non-ASCII characters coming from 'defaults read ...' to utf-8 because I want to simplify the interaction between BASH and tm_dialog. This works perfectly even with utf-16 surrogates.
But then I was a bit naïve! I thought that 'pl' outputs non-ASCII characters in the same way, but it didn't.
E.g. an German umlaut 'ö' stored in a xml plist format is outputted as '\U221a\U2202'!!
Has someone an idea what kind of 'format' it is? I found no documentation.
Or could it mean that 'pl' do not support utf-8 string at all?
Thanks for any hint
Hans
I believe I found a solution by myself.
Instead of using 'pl' you can do same with the command 'defaults read PLIST'. The only thing is that the encoding of non-ASCII characters is different from 'defaults read PLIST key'. I don't know why???? But anyway it should work.
On 17 Nov 2006, at 10:08, Hans-Joerg Bibiko wrote:
Hi,
sorry if my question is a bit off topic but I couldn't find any information.
I'm just writing a tiny perl script which converts non-ASCII characters coming from 'defaults read ...' to utf-8 because I want to simplify the interaction between BASH and tm_dialog. This works perfectly even with utf-16 surrogates.
But then I was a bit naïve! I thought that 'pl' outputs non-ASCII characters in the same way, but it didn't.
E.g. an German umlaut 'ö' stored in a xml plist format is outputted as '\U221a\U2202'!!
Has someone an idea what kind of 'format' it is? I found no documentation.
Or could it mean that 'pl' do not support utf-8 string at all?
Thanks for any hint
Hans
For new threads USE THIS: textmate@lists.macromates.com (threading gets destroyed and the universe will collapse if you don't) http://lists.macromates.com/mailman/listinfo/textmate
********************************************************** Hans-Joerg Bibiko Max Planck Institute for Evolutionary Anthropology Department of Linguistics Deutscher Platz 6 phone: +49 (0) 341 3550 341 D-04103 Leipzig fax: +49 (0) 341 3550 333 Germany e-mail: bibiko@eva.mpg.de **********************************************************
Here comes my solution:
I wrote two BASH scripts 'plutf8' and 'defaultsread'.
####### plutf8 MyPlist
will convert a XML property list in 'old-styled' plist encoded in utf8. (Hint: MyPlist without .plist extension!!)
example: C=$( plutf8 "$TM_BUNDLE_SUPPORT"/bin/HSDOut )
You also can pipe data to plutf8: example: DIA=$( cat "$TM_BUNDLE_SUPPORT"/bin/HSDOut.plist | tm_dialog -m hypersearch | plutf8 )
######## defaultsread <domain> <key>
reads the <key> from <domain> and converts it to utf8. (Hint: <domain> without .plist extension!!)
example: B=$( defaultsread "$TM_BUNDLE_SUPPORT"/bin/HSDOut searchString )
############
Both scripts also converts UTF-16 surrogates. So you can use it for Unicode characters which are specified above 0xFFFF. (Because I'm dealing with such characters a lot ;) )
So, if you are expecting such characters you can use these scripts instead of 'pl' and 'defaults read' and you will get what did you enter.
I put these scripts into $TM_SUPPORT_PATH/bin so there is no need to write the path.
Maybe these scripts are worth to put into the TM release (?)
Comments??
All the best,
Hans
Hi,
There is a tiny addition to both scripts. I redirect any error to the nirvana.
If an error occurs like you call 'defaultsread <domain> <key> and the key doesn't exist an empty string will be returned instead of an error message.
I think this is the best way (?)
Best,
Hans
On 17. Nov 2006, at 16:25, Hans-Joerg Bibiko wrote:
[...] I wrote two BASH scripts 'plutf8' and 'defaultsread'.
[...] Maybe these scripts are worth to put into the TM release (?)
Comments??
While I would certainly love to make it easier to work with plists from pure bash scripts, the problem is, that the old-style format does not support dates, booleans, and integers.
Booleans and integers I guess are fine as strings (0/1 for booleans). Dates, I am not sure what the best representation is, but probably the YYYY-MM-DDTHH:MM:SSZ variant.
But if this is only for shell, how about making a function exports them as variables? Then we can also have it use bash arrays for arrays.
On 17. Nov 2006, at 16:25, Hans-Joerg Bibiko wrote:
[...] I wrote two BASH scripts 'plutf8' and 'defaultsread'.
[...] Maybe these scripts are worth to put into the TM release (?)
Comments??
While I would certainly love to make it easier to work with plists from pure bash scripts, the problem is, that the old-style format does not support dates, booleans, and integers.
By myself I don't use pl or plutf8. I wrote it only for somebody who wants to use it.
Booleans and integers I guess are fine as strings (0/1 for booleans). Dates, I am not sure what the best representation is, but probably the YYYY-MM-DDTHH:MM:SSZ variant.
But if this is only for shell, how about making a function exports them as variables? Then we can also have it use bash arrays for arrays.
Well, I find it quite convenient to use 'defaults read/write/delete' out from bash. With 'export A=$(defaults ...)' you can publish BASH variables for other scripts. I use 'defaults write -array' and so forth to set plist before I send it to tm_dialog.
You mean that each variable coming from tm_dialog should be published as BASH variable. But then you have all variables even if you don't need some. E.g. I use one plist for two different tm_dialogs which share only one key.
Well, I will try to write such a function which reads for a speficied key(s) the value, array, date,... to put it in a BASH variable and a function which publish all keys from a plist as BASH variable.
Best,
Hans
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
On 18. Nov 2006, at 14:08, Hans-Joerg Bibiko wrote:
[...] You mean that each variable coming from tm_dialog should be published as BASH variable. But then you have all variables even if you don't need some. E.g. I use one plist for two different tm_dialogs which share only one key.
Probably only the variables in the result dictionary, assuming the user binds to selection.controller and uses the returnArgument: method to dismiss the dialog.
On 17. Nov 2006, at 10:08, Hans-Joerg Bibiko wrote:
[...] E.g. an German umlaut 'ö' stored in a xml plist format is outputted as '\U221a\U2202'!!
You need to set __CF_USER_TEXT_ENCODING, see http:// lists.macromates.com/pipermail/textmate/2006-October/014381.html
[...] Or could it mean that 'pl' do not support utf-8 string at all?
I don’t think the variable above is really endorsed by Apple, I tried to get some clear answers at WWDC, but the only thing I really got out of it was, that __CF_USER_TEXT_ENCODING is only for legacy mac- whatever encodings -- but then, I don’t think they really understood what I was talking about (as they kept telling me how I should place my non-ASCII strings in a *.strings file ;) ).
-
Allan Odgaard -
Hans-Joerg Bibiko