Julian Fitzell wrote:
> Jimmie Houchin wrote:
> [...]
>> It seems from browsing that the CrLfFileStream does much of that. The 
>> problem I was having is that I was using 
>> FileList2>>modalFileSelectorForSuffixes:  which returns a 
>> StandardFileStream.
>>
>> And as such my text file on Linux was full of 'lf's and the #nextLine 
>> was not working.
> [...]
> Oh god, tell me about it.  I encountered this a while back as well and 
> proposed that we habe FileList2 return a File class (a 
> so-far-non-existant class around which there has been much discussion 
> but no implementation :) instead of a stream.  There's really no reason 
> for it to return a stream directly - you might want to delete the file 
> you selected, not open it, for example.

Seems to be a common enough problem that the smart people on this list 
can come up with a consensus solution rather than each of us writing our 
own work arounds. I think that the File class solution sounds interesting.

I know in the case of FileList2 at one point I was working with MP3s and 
didn't need a FileStream at all but rather simply a FilePath so I added 
a couple methods to the FileList2 class on my work computer so that it 
would simply return the path string that I could then pass on the proper 
method.

> Anyway, you can change #concreteStream on... FileStream I think (just 
> search for the selector name) to use CrLfFileStrem instead of 
> StandardFileStream and then, as I recall, it will work... might cause 
> you other problems though :S

Thanks for the information. It will at least give me something to 
explore and learn.

I had heretofore when reasonable avoided the CrLfFileStream unless 
required because it dropped performance significantly as compared to 
StandardFileStream.

Jimmie Houchin