On Wed, 13 Aug 2014, Chris Cunningham wrote:

> hmm.  So, I was going back to find an old version of CrLfFileStream before MutliByteFileStream - that was a long time ago.  While looking, though, I found where at least the writing seems to have stopped
> doing the conversion:
> Name: Multilingual-ul.146
> Author: ul
> Time: 17 May 2011, 5:31:08.561 pm
> UUID: 8c0359ba-6c47-a946-9707-cc7c37dc8d44
> Ancestors: Multilingual-ul.145
> 
> MultiByteFileStream changes:
> - assume that wantsLineEndConversion is properly initialized
> - removed the line end conversion code from #nextPut:
> 
> Levente, do you happen to remember why you made MultiByteFileStream>>nextPut: not do the line end conversion code 3 years ago?

Because line end conversion is also done by the TextConverter (see
#installLineEndConventionInConverter), so it created double line endings
(cr -> crlf -> crlflf) in some cases, and it was unnecessary anyway.

I just checked if it works, and it does on linux:

| filename result |
filename := UUID new asString36, '.txt'.
FileStream newFileNamed: filename do: [ :file |
 	file
 		lineEndConvention: #crlf;
 		nextPut: Character cr;
 		nextPutAll: String cr;
 		lineEndConvention: #lf;
 		nextPut: Character cr;
 		nextPutAll: String cr;
 		lineEndConvention: #cr;
 		nextPut: Character cr;
 		nextPutAll: String cr;
 		lineEndConvention: nil;
 		nextPut: Character cr;
 		nextPutAll: String cr ].
result := FileStream readOnlyFileNamed: filename do: [ :file | file binary upToEnd ].
FileDirectory default deleteFileNamed: filename.
self assert: result = #[13 10 13 10 10 10 13 13 13 13]

Does it work on your machine?


Levente

> 
> (And apparently I've been annoyed about this for 3 years - but not enough to actually ask until now - bad me)
> 
> -cbc
> 
> 
> On Wed, Aug 13, 2014 at 3:30 PM, Chris Cunningham <cunningham.cb at gmail.com> wrote:
>       Good.  In that case I'll try to be a little more formal in the work, and share it, too.Can't promise it will be fast, though - off hours only.
> 
> -cbc
> 
> 
> On Wed, Aug 13, 2014 at 2:02 PM, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> 
> 
>
>       On Wed, Aug 13, 2014 at 1:57 PM, Chris Cunningham <cunningham.cb at gmail.com> wrote:
>             Hi.
> so, for a while now, I've been annoyed that the newer Squeak's didn't really handle Windows nicely - at least, not writing to files to handle outside of Squeak.  Today I finally dug into the
> code to find out why.
> 
> Many moons ago, MultiByteFileStream was created as the replacement fo rCrLfFileStream, and most references to CrLfFileStream went away.  Which is even commented in the code(!), as:
> It also combined the good old CrLfFileStream.  CrLfFileStream class>>new now returns an instance of MultiByteFileStream.
> 
> However, the conversion wasn't complete.  In particular:
> FileDirectory>>newFileNamed: (and related things) just get a new MutliByteFileStream, which doesn't activate any of the CrLf lineEnding magic - it assume there is no line ending conversions
> wanted at all.
> In fact, no way to use MutliBytFileStream (except as CrLfFileStream new, from that obsoleted class) really use it (exceptions being FileList and BDFFontReader).  This is annoying on a system
> that doesn't use cr as the default line endings (are there any left?).
> 
> Further, if you do set it up to detect line endings, as far as I can tell, it never actually does any conversions!
> 
> Would anyone mind if I finished putting the CrLfFileStream functionality into MultiByteFileStream?  and if I did it, would anyone else use it?
> 
> 
> I would be pleased!  I can't promise to use it, but I /want/ to produce a build server for WIndows that includes producing VM source, building it, etc, and as part of that I would test that
> sources can be produced *without* CR-LF, but with plain LF line-endings.
> 
> --
> best,Eliot
> 
> 
> 
> 
> 
> 
>