Unicode is not "everywhere"...

[Dar Scott Consulting]

But that isn't the issue. Well, not what I thought the issue was.

If shell() only returns binary, as suggested by the mention of textDecode(), then binary data must always have an interpretation as a string to keep from breaking legacy code. Currently, that is interpreted as an 8-bit character of a character set of which ASCII is a subset. So, I'm OK with shell() being clarified to return binary data, which might be pure byte stream, some Unicode encoded data, or other character encoded data.  That is, unless one is using ASCII, then textDecode should be used, and even with ASCII, it may be used.

I'm also OK with shell() returning a string with no loss intermediate conversions.  I can use "open process" for binary data, if fixed.



> On Aug 22, 2019, at 2:17 PM, Paul Dupuis via use-livecode <use-livecode at lists.runrev.com> wrote:
> 
> On 8/22/2019 4:08 PM, Richard Gaskin via use-livecode wrote:
>> Dar Scott wrote:
>> 
>> > If the result of shell() is run through textDecode, should then
>> > shell() return binary data? This puts it outside the scope of
>> > "everywhere". I like the idea, as long as simple ASCII characters
>> > work transparently.
>> 
>> Isn't that the goal of UTF-8, which is why so many programming languages uses it as the default?
>> 
> 
> Richard is correct. UTF8 encoding does not change readability of ASCII characters.
> Encoding the results from shell as UTF8 does mean that ASCII characters can be used in a return values without text decoding. shell() under OSX, at least tested under LC905rc1, actually returns UTF8 and probably no one using shell on OSX has noticed if you've just been working with ASCII characters as the output of your shell comamnd.
> 
> 
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode