On 13 Feb 2007, at 17:17, Andrew P. Black wrote:

> I have noticed that CrLfFileStream class >>  
> guessDefaultLineEndConvention does not work on my MacOSX system
>
> DirectoryClass (a class variable, defined in class FileDirectory)  
> is  UnixFileDirectory on my system, which seems reasonable — but   
> that class hard-codes the path separator to be /, which  
> guessDefaultLineEndConvention uses to guess that LF is the right  
> line ending convention.
>
> This explains, perhaps, why LF characters are increasingly  
> polluting the sources and changes files.

I deathly silence followed this post, which lead me to suspect that I  
had said something very foolish.  However, I haven't been able to  
figure out what.    Perhaps if I continue to prattle on, someone will  
tell me.

The value of LineEndDefault seems to matter only when creating a new  
file; when reading a file, or over-writing a file, the existing  
content of the file governs whether the cr message writes LF or CR,  
and what line endings cause next to answer CR.

However, when it matters, it matters.  I can't be the only MacOSX  
user to notice that writing a text file fills it with LFs!

The fix seems to be simple: check to see if we are running on Darwin.

CrLfFileStream class >> guessDefaultLineEndConvention
	"Lets try to guess the line end convention from what we know about the
	path name delimiter from FileDirectory and the identity of the OS."
	FileDirectory pathNameDelimiter = $:
		ifTrue: [^ self defaultToCR].
	FileDirectory pathNameDelimiter = $/
		ifTrue: [((SmalltalkImage current getSystemAttribute: 1002)  
beginsWith: 'darwin')
				ifTrue: [^ self defaultToCR]
				ifFalse: [^ self defaultToLF]].
	FileDirectory pathNameDelimiter = $\
		ifTrue: [^ self defaultToCRLF].
	"in case we don't know"
	^ self defaultToCR


Shall I submit this as a bugfix?

	Andrew