The differences are caused by differences in the C libraries on
different machines: ANSI C requires/allows stdio to convert \n into
whatever is used to mark end of line on the local machine.
>From memory, I believe that Haskell's IO spec follows this example.
(Whether it does or not, though, Hugs uses the ANSI C library so that's
what's causing the problem.)
There are two fixes:
1) When tranferring the file from one machine to another, use an appropriate
translation mechanism to convert formats. (I think you
can setup NFS, Samba, etc to do this too - but I could be wrong.)
Back in the days of VMS and EBCDIC, it was pretty much standard to do so.
Nowadays the differences are slight enough that we tend to forget the need.
2) If you really, really want absolute control over what's going into your
files, use these functions (from IOExtensions):
writeBinaryFile :: FilePath -> String -> IO ()
appendBinaryFile :: FilePath -> String -> IO ()
readBinaryFile :: FilePath -> IO String
openBinaryFile :: FilePath -> IOMode -> IO Handle
These are good for things like generating MIDI files.
Note that these are non-standard extensions which are very unlikely
to be provided by other Haskell implementations because they
provide the same functionality in other (Haskell98-conforming)
ways.
--
Alastair Reid
> I am using Basic Hugs, Jun 20 1999, on Mac OS 8.6.
>
> The following session appears to do the right thing:
>
> Prelude> writeFile "test" $ map chr [0..15]
>
> Prelude> do {f <- readFile "test"; putStr $ show $ map ord f}
> [0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15]
> Prelude>
>
>
> But if I do a hex dump of the file "test" I get:
>
> 00 01 02 03 04 05 06 07 08 09 0D 0B 0C 0A 0E 0F ................
> ^^ ^^
>
> If I create the file "test" using Hugs on a Unix system then read it using
> Mac Hugs I get:
>
> [0,1,2,3,4,5,6,7,8,9,13,11,12,10,14,15]
> ^^ ^^
>
> It appears that Mac Hugs switches \r and \n characters when it reads and
> writes files.
