Results change in BBEdit 11.6: whose fault?

I ran into an issue running a script that takes the result of the svn command line’s ‘status’ and ‘diff’ commands, massages them a bit, and sends them to BBEdit. Specifically, the line endings are mangled.

The BBEdit 11.6 Release Notes include this:

BBEdit now uses the line feed (ASCII decimal 10) as line breaks in its internal representation for text in open documents, instead of the carriage return (ASCII decimal 13) that was the standard Mac format for many years. This (theoretically) reduces the time required to open documents, since in the normal case, no conversion is necessary; it also eliminates conversion logic when copying and pasting text, since LF-delimited text is also the standard interchange format on the Clipboard.

And it seems logical that the command line results use linefeed (ASCII 10) as well, but when my script sends the results to BBEdit, the line endings are mangled. (There’s is some combining and massaging of the results, in case you are wondering why I don’t just pipe it directly to BBEdit.)

I have found two workarounds: Modify my script to include the BBEdit command “normalize line endings” or use BBEdit 11.5.

I wrote to Bare Bones, and Rich Siegel suggested (and I agree) that this seems to be an AppleScript issue, as piping directly from the command line to BBEdit works fine. I’ve sent him a copy of the script for testing, but he requested that I ‘ask about’ to see if anybody with more AppleScript expertise has any useful insights. Hence, this topic.

BTW, this is happening in macOS 10.10.5.

Hey Matt,

do shell script "your script text" without altering line endings

https://developer.apple.com/library/mac/technotes/tn2065/_index.html


By default, do shell script transforms all the line endings in the result to Mac-style carriage returns ("\r" or ASCII character 13), and removes a single trailing line ending, if one exists. This means, for example, that the result of do shell script “echo foo; echo bar” is “foo\rbar”, not the “foo\nbar\n” that echo actually returned. You can suppress both of these behaviors by adding the without altering line endings parameter. For dealing with non-ASCII data, see Dealing with Text.


-Chris

3 Likes

Thanks for the info. It’s rather stunning that this “Unix tool” does that. Seems upside down to me: the optional parameter ought to be require to alter the text.

Thanks again.

But it’s not a “Unix tool” – it’s an AppleScript tool.

Isn’t that sort of pedantic, and not at all helpful? Would it be better if I had written “this tool that allows AppleScript to access the Unix underbelly of macOS?” It’s definitely more wordy and doesn’t add anything in understanding.

I’d love to know how many hits that page has had in its lifetime.

I must have read it a couple of dozen times myself, and yet there’s STILL stuff in it I didn’t know about (like this line ending stuff).

Y’gotta love ‘do shell script’. It’s just has all the coolest madness of all the mad things that there are in AppleScript! :sunglasses:

Hey Matt,

It’s only peculiar in retrospect. When the do shell script command was made available linefeeds were still largely considered anathema on Macs.

The fact that the AppleScript compiler still uses carriage returns is stranger still.

-Chris

So AppleScript is lagging behind in the migration from Classic to OS X. Imagine that. :unamused:

Is there any other part of macOS that uses CR instead of LF? Color me dubious.

It’s not meant to be. When you use osascript, it’s a Unix tool and follows the Unix conventions. do shell script is an AppleScript command.

Part of the problem is having optional parameters: defaults tend to reflect the times they are introduced. do shell script was introduced in OS X 10.1. At the time, much of the Mac world was still MacRoman-based. (Indeed, a lot of Unix stuff was still ASCII-based.) There was no linefeed variable; you had to use ASCII character 10. So taking the results of something like ls and making a list would have been a lot more complicated than today’s paragraphs of ... if the result were unmodified.

Times have obviously changed, but that leaves two choices: change the default, and potentially break a huge number of scripts, or let people who require the Unix-like result simply include the optional parameter. Obviously Apple has done the latter.

It’s not like it’s a secret or that you have to read the tech note – it’s there in the Standard Additions command:

(I guess you can quibble over what “Mac-style” means, but it’s clear that something is being changed.)

AppleScript lags in zillions of ways. But I think this is simply a case of maintaining backwards compatibility. It’s the same as the read and write commands, which are stuck with the MacRoman default.