[Pharo-dev] Default line endings while writing to a file stream

Ben Coman btc at openinworld.com
Fri May 31 01:06:51 EDT 2019

I'm on Windows wanting to write a text file with LF endings.
The code developed on Linux is thus...
    (destinationDirectory / 'README.md') ensureCreateFile
            writeStreamDo: [ :stream | stream nextPutAll: class comment ]

and I am stuck with CR line endings.
The specific symptom is that it screws `git diff`
Here is a simple experiment...
    testfile := 'README.md' asFileReference.
    testfile ensureCreateFile writeStreamDo: [ :stream |
    stream nextPutAll: 'aa
bb' ].
    testfile binaryReadStream contents at: 3      "==>  Character cr "

I think its safe to assume on Linux that will result in "==>  Character lf "
but can someone please confirm?

So my issue is that I've got
    #ensureCreateFile - returns a FileReference
    :stream - is a ZnCharacterWriteStream wrapping a ZnBufferedWriteStream
wrapping BinaryFileStream.

and neither seem to have an easily accessible defaultLineEnding setting.
Indeed, line endings are not a property of FileReference
and Binary & Characters have nothing to do with line endings,
and questionable if Buffering is related.

Its more a property of a File, but IIUC that is being deprecated (??)

MultiByteFileStream has #lineEndConvention:
but IIUC that also is being deprecated.

So what is the proper way to force default line endings?

Now while composing this email I discovered String>>withUnixLineEndings.
So I have a solution...
    testfile := 'README.md' asFileReference.
    testfile ensureCreateFile writeStreamDo: [ :stream |
    stream nextPutAll: 'aa
bb'  withUnixLineEndings ].
    (testfile binaryReadStream contents at: 3) asCharacter   "==> Character
lf "

but that seems to imply that on Windows...
bb' at: 3  "==> Character cr "

and on Linux (someone please confirm)...
bb' at: 3   "==> Character lf "

and that is *very* curious.  Strange that I never noticed it before and
obviously that hasn't hurt me,
but considering the Principal Of Least Surprise it leaves me feeling
somewhat violated :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20190531/4da0cd25/attachment-0001.html>

More information about the Pharo-dev mailing list