win32-dlls.xml whitespace

diff --git a/docs/users_guide/win32-dlls.xml b/docs/users_guide/win32-dlls.xml
index 44f589a..ad1c788 100644 (file)
--- a/docs/users_guide/win32-dlls.xml
+++ b/docs/users_guide/win32-dlls.xml
@@ -23,7 +23,7 @@ interpret the filename as two, "c:\\Program" and "Files\\Haskell\\Project.hs".
 <!-- not clear whether there are current editions of Win32 OSes that
      doesn't do this by default.
 
 <!-- not clear whether there are current editions of Win32 OSes that
      doesn't do this by default.
 

-<para> Solution: don't use "Open With...", avoid spaces in file names, 
+<para> Solution: don't use "Open With...", avoid spaces in file names,

 or fiddle with the appropriate registry setting:
 <programlisting>
   HKEY_CLASSES_ROOT\Unknown\shell\openas\command
 or fiddle with the appropriate registry setting:
 <programlisting>
   HKEY_CLASSES_ROOT\Unknown\shell\openas\command

@@ -152,7 +152,7 @@ cygwin's bash), but what matters here is that - just like any other
 normal windows program - neither GHC nor the executables it produces
 are aware of cygwin's pretended unix hierarchy. GHC will happily
 accept either '/' or '\' as path separators, but it won't know where
 normal windows program - neither GHC nor the executables it produces
 are aware of cygwin's pretended unix hierarchy. GHC will happily
 accept either '/' or '\' as path separators, but it won't know where

-to find <filename>/home/joe/Main.hs</filename> or <filename>/bin/bash</filename> 
+to find <filename>/home/joe/Main.hs</filename> or <filename>/bin/bash</filename>

 or the like. This causes all
 kinds of fun when GHC is used from within cygwin's bash, or in
 make-sessions running under cygwin.
 or the like. This causes all
 kinds of fun when GHC is used from within cygwin's bash, or in
 make-sessions running under cygwin.

@@ -162,9 +162,9 @@ make-sessions running under cygwin.
 <sect2><title>Things to do</title>
 <itemizedlist>
 <listitem>
 <sect2><title>Things to do</title>
 <itemizedlist>
 <listitem>

-<para> Don't use absolute paths in make, configure &amp; co if there is any chance 
+<para> Don't use absolute paths in make, configure &amp; co if there is any chance

   that those might be passed to GHC (or to GHC-compiled programs). Relative
   that those might be passed to GHC (or to GHC-compiled programs). Relative

-  paths are fine because cygwin tools are happy with them and GHC accepts 
+  paths are fine because cygwin tools are happy with them and GHC accepts

   '/' as path-separator. And relative paths don't depend on where cygwin's
   root directory is located, or on which partition or network drive your source
   tree happens to reside, as long as you 'cd' there first.
   '/' as path-separator. And relative paths don't depend on where cygwin's
   root directory is located, or on which partition or network drive your source
   tree happens to reside, as long as you 'cd' there first.

@@ -175,25 +175,25 @@ make-sessions running under cygwin.
   <literal>ROOT=`pwd`</literal> in makefile hierarchies or configure scripts), cygwin provides
   a tool called <command>cygpath</command> that can convert cygwin's unix-style paths to their
   actual windows-style counterparts. Many cygwin tools actually accept
   <literal>ROOT=`pwd`</literal> in makefile hierarchies or configure scripts), cygwin provides
   a tool called <command>cygpath</command> that can convert cygwin's unix-style paths to their
   actual windows-style counterparts. Many cygwin tools actually accept

-  absolute windows-style paths (remember, though, that you either need 
-  to escape '\' or convert '\' to '/'), so you should be fine just using those 
-  everywhere. If you need to use tools that do some kind of path-mangling 
-  that depends on unix-style paths (one fun example is trying to interpret ':' 
-  as a separator in path lists..), you can still try to convert paths using 
+  absolute windows-style paths (remember, though, that you either need
+  to escape '\' or convert '\' to '/'), so you should be fine just using those
+  everywhere. If you need to use tools that do some kind of path-mangling
+  that depends on unix-style paths (one fun example is trying to interpret ':'
+  as a separator in path lists..), you can still try to convert paths using

   <command>cygpath</command> just before they are passed to GHC and friends.
 </para></listitem>
   <command>cygpath</command> just before they are passed to GHC and friends.
 </para></listitem>

-  
+

 <listitem>
 <para> If you don't have <command>cygpath</command>, you probably don't have cygwin and hence
   no problems with it... unless you want to write one build process for several
   platforms. Again, relative paths are your friend, but if you have to use
   absolute paths, and don't want to use different tools on different platforms,
   you can simply write a short Haskell program to print the current directory
 <listitem>
 <para> If you don't have <command>cygpath</command>, you probably don't have cygwin and hence
   no problems with it... unless you want to write one build process for several
   platforms. Again, relative paths are your friend, but if you have to use
   absolute paths, and don't want to use different tools on different platforms,
   you can simply write a short Haskell program to print the current directory

-   (thanks to George Russell for this idea): compiled with GHC, this will give 
-  you the view of the file system that GHC depends on (which will differ 
+   (thanks to George Russell for this idea): compiled with GHC, this will give
+  you the view of the file system that GHC depends on (which will differ

   depending on whether GHC is compiled with cygwin's gcc or mingw's
   depending on whether GHC is compiled with cygwin's gcc or mingw's

-  gcc or on a real unix system..) - that little program can also deal with 
-  escaping '\' in paths. Apart from the banner and the startup time, 
+  gcc or on a real unix system..) - that little program can also deal with
+  escaping '\' in paths. Apart from the banner and the startup time,

   something like this would also do:
 <programlisting>
   $ echo "Directory.getCurrentDirectory >>= putStrLn . init . tail . show " | ghci
   something like this would also do:
 <programlisting>
   $ echo "Directory.getCurrentDirectory >>= putStrLn . init . tail . show " | ghci

@@ -258,7 +258,7 @@ cured the problem (it was supposedly fixed some years ago).
 The default on Win32 platforms is to link applications in such a way
 that the executables will use the Prelude and system libraries DLLs,
 rather than contain (large chunks of) them. This is transparent at the
 The default on Win32 platforms is to link applications in such a way
 that the executables will use the Prelude and system libraries DLLs,
 rather than contain (large chunks of) them. This is transparent at the

-command-line, so 
+command-line, so

 </para>
 
 <para>
 </para>
 
 <para>

@@ -273,7 +273,7 @@ sh$ ls -l main.exe
 -rwxr-xr-x   1 544      everyone     4608 May  3 17:11 main.exe*
 sh$ ./main
 hello, world!
 -rwxr-xr-x   1 544      everyone     4608 May  3 17:11 main.exe*
 sh$ ./main
 hello, world!

-sh$ 
+sh$

 </screen>
 </para>
 
 </screen>
 </para>