Fix typos where "it's" should be "its".

Changelog

@@ -350,7 +350,7 @@ Revision history for Perl extension IPC::Run
 	- The debug file descriptor is built by dup()ing STDERR in the parent and
 	  passing it to the kids.  This keeps us from needing to worry about
 	  debugging info in the select() loop and removes unnecessary complications.
-	  Still needs a bit of work: it should be dup()ed in _open_pipes and it's
+	  Still needs a bit of work: it should be dup()ed in _open_pipes and its
 	  value should be stored in the harness, not a global.
 	- child processes are now a little more clearly identified in debug output.
 	- Some debugging messages are now clearer.

README.md

@@ -578,7 +578,7 @@ Here are some of the issues you might need to be aware of.
     This can make it hard to guarantee that your output parser won't be fooled
     into early termination of results.
 
-    To help work around this, you can see if the program can alter it's 
+    To help work around this, you can see if the program can alter its
     prompt, and use something you feel is never going to occur in actual
     practice.
 
@@ -611,7 +611,7 @@ Here are some of the issues you might need to be aware of.
 
     Some programs don't prompt unless stdin or stdout is a tty.  See if you can
     turn prompting back on.  If not, see if you can come up with a command that
-    you can issue after every real command and look for it's output, as
+    you can issue after every real command and look for its output, as
     IPC::ChildSafe does.   There are two filters included with IPC::Run that
     can help with doing this: appender and chunker (see new\_appender() and
     new\_chunker()).
@@ -833,7 +833,7 @@ The SHNP field indicates what parameters an operator can take:
     The subroutine will be called each time some data is read from the child.
 
     The >pipe operator is different in concept than the other '>' operators,
-    although it's syntax is similar:
+    although its syntax is similar:
 
         $h = start \@cat, $in, '>pipe', \*OUT, '2>pipe', \*ERR;
         $in = "hello world\n";
@@ -1114,7 +1114,7 @@ in their exit codes.
 >     someday, spawn()) all the child processes.  It does not send or receive any
 >     data on the pipes, see pump() and finish() for that.
 >
->     You may call harness() and then pass it's result to start() if you like,
+>     You may call harness() and then pass its result to start() if you like,
 >     but you only need to if it helps you structure or tune your application.
 >     If you do call harness(), you may skip start() and proceed directly to
 >     pump.
@@ -1663,7 +1663,7 @@ High resolution timeouts.
 
     Being a race condition, it's hard to reproduce, but I encountered it while
     testing this code on a drive share to a samba box.  In this case, it takes
-    t/run.t a long time to spawn it's child processes (the parent hangs in the
+    t/run.t a long time to spawn its child processes (the parent hangs in the
     first select for several seconds until the child emits any debugging output).
 
     I have not seen it on local drives, and can't reproduce it at will,

lib/IPC/Run.pm

@@ -588,7 +588,7 @@ listing.
 This can make it hard to guarantee that your output parser won't be fooled
 into early termination of results.
 
-To help work around this, you can see if the program can alter it's 
+To help work around this, you can see if the program can alter its
 prompt, and use something you feel is never going to occur in actual
 practice.
 
@@ -625,7 +625,7 @@ Not prompting unless connected to a tty.
 
 Some programs don't prompt unless stdin or stdout is a tty.  See if you can
 turn prompting back on.  If not, see if you can come up with a command that
-you can issue after every real command and look for it's output, as
+you can issue after every real command and look for its output, as
 IPC::ChildSafe does.   There are two filters included with IPC::Run that
 can help with doing this: appender and chunker (see new_appender() and
 new_chunker()).
@@ -855,7 +855,7 @@ does the same basic thing as:
 The subroutine will be called each time some data is read from the child.
 
 The >pipe operator is different in concept than the other '>' operators,
-although it's syntax is similar:
+although its syntax is similar:
 
    $h = start \@cat, $in, '>pipe', \*OUT, '2>pipe', \*ERR;
    $in = "hello world\n";
@@ -1452,7 +1452,7 @@ sub _spawn {
     }
     _debug "fork() = ", $kid->{PID} if _debugging_details;
 
-    ## Wait for kid to get to it's exec() and see if it fails.
+    ## Wait for kid to get to its exec() and see if it fails.
     _close $self->{SYNC_WRITER_FD};
     my $sync_pulse = _read $sync_reader_fd;
     _close $sync_reader_fd;
@@ -2749,7 +2749,7 @@ after building all of the pipes and launching (via fork()/exec(), or, maybe
 someday, spawn()) all the child processes.  It does not send or receive any
 data on the pipes, see pump() and finish() for that.
 
-You may call harness() and then pass it's result to start() if you like,
+You may call harness() and then pass its result to start() if you like,
 but you only need to if it helps you structure or tune your application.
 If you do call harness(), you may skip start() and proceed directly to
 pump.
@@ -3161,7 +3161,7 @@ sub _select_loop {
         #   FILE:
         #      for my $pipe ( @pipes ) {
         #         ## Pipes can be shared among kids.  If another kid closes the
-        #         ## pipe, then it's {FD} will be undef.  Also, on Win32, pipes can
+        #         ## pipe, then its {FD} will be undef.  Also, on Win32, pipes can
         #	 ## be optimized to be files, in which case the FD is left undef
         #	 ## so we don't try to select() on it.
         #         if ( $pipe->{TYPE} =~ /^>/
@@ -4348,7 +4348,7 @@ closing the parent socket.
 
 Being a race condition, it's hard to reproduce, but I encountered it while
 testing this code on a drive share to a samba box.  In this case, it takes
-t/run.t a long time to spawn it's child processes (the parent hangs in the
+t/run.t a long time to spawn its child processes (the parent hangs in the
 first select for several seconds until the child emits any debugging output).
 
 I have not seen it on local drives, and can't reproduce it at will,

lib/IPC/Run/Timer.pm

@@ -24,7 +24,7 @@ IPC::Run::Timer -- Timer channels for IPC::Run.
 =head1 DESCRIPTION
 
 This class and module allows timers and timeouts to be created for use
-by IPC::Run.  A timer simply expires when it's time is up.  A timeout
+by IPC::Run.  A timer simply expires when its time is up.  A timeout
 is a timer that throws an exception when it expires.
 
 Timeouts are usually a bit simpler to use  than timers: they throw an

lib/IPC/Run/Win32Helper.pm

@@ -373,7 +373,7 @@ Cannot redirect higher file descriptors due to lack of support for this in the
 Win32 environment.
 
 This can be worked around by marking a handle as inheritable in the
-parent (or leaving it marked; this is the default in perl), obtaining it's
+parent (or leaving it marked; this is the default in perl), obtaining its
 Win32 handle with C<Win32API::GetOSFHandle(FH)> or
 C<Win32API::FdGetOsFHandle($fd)> and passing it to the child using the command
 line, the environment, or any other IPC mechanism (it's a plain old integer).

t/lib/Test.pm

@@ -127,7 +127,7 @@ sub filter_tests($;@) {
         is(
             scalar @input,
             0,
-            "$name didn't consume it's input"
+            "$name didn't consume its input"
         );
     }