doc: minor spell checkings etc while reading

Author: yarikoptic

doc/users/caching_tutorial.rst

@@ -130,18 +130,18 @@ rather than workflows. Use it: instead of data grabber nodes, use for
 instance the `glob` module. To vary parameters, use `for` loops. To make
 reusable code, write Python functions.
 
-One good rule of thumb to respect is to avoid the usage of explicite
-filenames appart from the outermost inputs and outputs of your
+One good rule of thumb to respect is to avoid the usage of explicit
+filenames apart from the outermost inputs and outputs of your
 processing. The reason being that the caching mechanism of
 :mod:`nipy.caching` takes care of generating the unique hashes, ensuring
-that, when you vary parameters, files are not overriden by the output of
+that, when you vary parameters, files are not overridden by the output of
 different computations.
 
 .. topic:: Debuging
 
     If you need to inspect the running environment of the nodes, it may
     be useful to know where they were executed. With `nipype.caching`,
-    you do not control this location as it it encoded by hashes.
+    you do not control this location as it is encoded by hashes.
 
     To find out where an operation has been persisted, simply look in
     it's output variable::

doc/users/function_interface.rst

@@ -48,7 +48,7 @@ Which would print ``4``.
 
 Note that, if you are working interactively, the Function interface is
 unable to use functions that are defined within your interpreter session.
-(Specifcally, it can't use functions that live in the ``__main__`` namespace).
+(Specifically, it can't use functions that live in the ``__main__`` namespace).
 
 Using External Packages
 -----------------------
@@ -59,7 +59,7 @@ geared towards neuroimaging, such as Nibabel_, Nipy_, or PyMVPA_.
 
 While this is completely possible (and, indeed, an intended use of the
 Function interface), it does come with one important constraint. The
-function code you write is excecuted in a standalone environment, 
+function code you write is executed in a standalone environment, 
 which means that any external functions or classes you use have to
 be imported within the function itself::
 
@@ -77,7 +77,7 @@ Hello World - Function interface in a workflow
 Contributed by: Hänel Nikolaus Valentin 
 
 The following snippet of code demonstrates the use of the function interface in
-the context of a workflow. Note the use of `import os` within the function as
+the context of a workflow. Note the use of ``import os`` within the function as
 well as returning the absolute path from the Hello function. The `import` inside
 is necessary because functions are coded as strings and do not have to be on the
 PYTHONPATH. However any function called by this function has to be available on
@@ -139,7 +139,7 @@ the string would be
     add_two_str = "def add_two(val):\n    return val + 2\n"
 
 Unlike when using a function object, this input can be set like any other,
-meaning that you could write a function that outputs differnet function
+meaning that you could write a function that outputs different function
 strings depending on some run-time contingencies, and connect that output
 the the ``function_str`` input of a downstream Function interface. 
 

doc/users/grabbing_and_sinking.rst

@@ -37,7 +37,7 @@ to simply iterate over subjects.
 
 However, in the context of complex workflows and given that users typically
 arrange their imaging and other data in a semantically hierarchical data store,
-an alternate mechanism for reading and writing the data generated by a workflow
+an alternative mechanism for reading and writing the data generated by a workflow
 is often necessary. As the names suggest DataGrabber is used to get at data
 stored in a shared file system while DataSink is used to store the data
 generated by a workflow into a hierarchical structure on disk.
@@ -46,8 +46,8 @@ generated by a workflow into a hierarchical structure on disk.
 DataGrabber
 ===========
 
-Datagrabber is an interface for collecting files from hard drive. It is very
-flexible and supports almost any file organisation of your data you can imagine.
+DataGrabber is an interface for collecting files from hard drive. It is very
+flexible and supports almost any file organization of your data you can imagine.
 
 You can use it as a trivial use case of getting a fixed file. By default,
 DataGrabber stores its outputs in a field called outfiles.
@@ -60,7 +60,7 @@ DataGrabber stores its outputs in a field called outfiles.
   datasource1.inputs.template = 'data/s1/f3.nii'
   results = datasource1.run()
 
-Or you can get at all uncompressed nifti files starting with the letter 'f' in
+Or you can get at all uncompressed NIfTI files starting with the letter 'f' in
 all directories starting with the letter 's'.
 
 ::
@@ -75,7 +75,7 @@ path matches of the form `/mass/data/s*/f*`.
 
 .. note::
 
-  When used with wildcards (e.g., s* and f* above) Datagrabber does not return
+  When used with wildcards (e.g., s* and f* above) DataGrabber does not return
   data in sorted order. In order to force it to return data in sorted order, one
   needs to set the input `sorted = True`. However, when explicitly specifying an
   order as we will see below, `sorted` should be set to `False`.
@@ -108,7 +108,7 @@ A more realistic use-case
 
 In a typical study one often wants to grab different files for a given subject
 and store them in semantically meaningful outputs. In the following example, we
-wish to retrieve all the functional runs and the structural image for subject 's1'.
+wish to retrieve all the functional runs and the structural image for the subject 's1'.
 
 ::
 
@@ -147,7 +147,7 @@ iterables that have been used in the workflow. This makes navigating the working
 directory a not so pleasant experience. And typically the user is interested in
 preserving only a small percentage of these outputs. The DataSink interface can
 be used to extract components from this `cache` and store it at a different
-location. For XNAT-based storage, see XNATSink.
+location. For XNAT-based storage, see :class:`nipype.interfaces.io.XNATSink` .
 
 .. note:: 
 

doc/users/install.rst

@@ -39,13 +39,13 @@ Debian and Ubuntu
 ~~~~~~~~~~~~~~~~~
 
 Add the `NeuroDebian <http://neuro.debian.org>`_ repository and install
-the ``python-nipype`` package using ``apt-get`` or your favourite package
+the ``python-nipype`` package using ``apt-get`` or your favorite package
 manager.
 
 Mac OS X
 ~~~~~~~~
 
-The easiest way to get nipype running on MacOSX is to install EPD_ and then add
+The easiest way to get nipype running on Mac OS X is to install EPD_ and then add
 nibabel and nipype by executing::
 
 	easy_install nibabel