UKenGB wrote: ↑
Wed Feb 21, 2018 10:21 am
The WRONG assumption has been made that the Mac always and only uses CR and here we have the result of that (fundamentally ignorant if truth be told) mistake.
I agree with the sentiment, and wish the circumstances were different. I sometimes even share the same thought about "legacy be damned, let's change it now!". But then I think of the hundreds of hours I'd be spending rewriting so much code, and the hundreds of thousands of hours lost to our community doing the same, and then I think maybe that LiveCode being no more immune to its own historical anomalies than any other language isn't so bad, even if it does mean having to learn an anomaly or two along the way.
Some background may be helpful:
It was neither wrong nor an assumption when the "CR" and "return" constants were first introduced in the root tongue of this family of languages, HyperTalk. In fact, HyperTalk was made by Apple itself, so while no company is perfect we can be reasonably confident the decision wasn't entirely without some merit.
This is one of the challenges with a mature multi-platform tool: if LC were being invented today it wouldn't be influenced by something as old as the pre-NeXT Mac OS (what we now think of as "Classic").
But before it was LiveCode it was MetaCard, which was born in May 1992. In those days Apple's own HyperCard introduced "CR" and "return" as constants for 0x13, which was the only line-ending used on Apple's OS at the time.
And while one of the greatest strengths of LiveCode is its multi-platform nature, for MetaCard's first half-decade it was exclusively Unix, which of course uses LF for line endings. Scripts, fields, and other internal representations of text used the Unix convention for line endings, which is still the case to this day.
To allow HyperCard scripts to be run within MetaCard without modification, MetaCard implemented support for the "CR" and "return" constants in a way that worked well on Unix, as 0x10. Oddly enough, even major MetaCard users like Sun didn't seem to mind the anomaly too much; it was something to learn, and once learned was easy to accommodate.
Back then no one could know that nearly a decade later Apple would toss their OS and replace it with a Unix system, NeXT. But just after the turn of this century they did, and line endings on Mac have been a jumbled mish-mash of mixed conventions ever since.
Some macOS programs continue to use 0x13 for line endings, but things unique to the newer Unix implementation like Terminal use the Unix convention instead.
In the olden days, the only time Mac users had to think about translating line endings was when trading files with Windows users. But today we find posts in support forums around the Mac community about translating line endings within macOS itself.
Given that so much of the modern world is driven by Unix conventions, I'm glad Apple made the switch. NeXT was an especially good Unix, and in Apple's hands it's only gotten better.
And ideally Windows would also change to Unix, and then with just one set of conventions so much in computing would be simplified.
But in the meantime we find ourselves on an imperfect planet, on which humans evolved as imperfect creatures who make imperfect decisions. Line-ending anomalies are annoying as hell, and in all honesty I'm no fan of the legacy that brought us here either. But in the bigger picture, line-ending anomalies are among the least impactful of human imperfections.
Indeed, you probably wouldn't have even had to think about line endings were it not for the specific characteristics of using Terminal on macOS:
Within LC those constants display text as expected.
And when reading and writing text, LC's automatic conversion to and from OS-native line endings on all platforms delivers results that display as expected.
But because Terminal uses Unix line endings on an OS that otherwise displays 0x13 just fine, we encounter one of the few cases where we see unexpected results. In that specific case the results are even more mystifying than other outcomes of line-ending differences among platforms, because the macOS Terminal overwrites your output with its prompt, giving the false appearance that nothing was written at all (introduce a wait and you'll see what I mean).
Given how seldom macOS is used for servers (Apple themselves use Linux), the scope of impact from this historical anomaly is pretty small.
So it's annoying, and one of the many things we need to keep in mind when working with binary data. But for most practical needs, LC's handling of line endings across platforms, imperfect as it is, does a pretty good job of balancing backward compatibility, OS expectations, and internal consistency.