From 01b7780bf5085e05e1eef3e36d8d1fb36d3bb53d Mon Sep 17 00:00:00 2001 From: Noah Misch Date: Sat, 9 Mar 2024 08:38:49 -0800 Subject: [PATCH] Fix typos where "it's" should be "its". --- Changelog | 2 +- README.md | 10 +++++----- lib/IPC/Run.pm | 14 +++++++------- lib/IPC/Run/Timer.pm | 2 +- lib/IPC/Run/Win32Helper.pm | 2 +- t/lib/Test.pm | 2 +- 6 files changed, 16 insertions(+), 16 deletions(-) diff --git a/Changelog b/Changelog index 8e7c25d..1d11fe6 100644 --- a/Changelog +++ b/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. diff --git a/README.md b/README.md index 105557f..502e647 100644 --- a/README.md +++ b/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, diff --git a/lib/IPC/Run.pm b/lib/IPC/Run.pm index 5b53cb8..76a41a1 100644 --- a/lib/IPC/Run.pm +++ b/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, diff --git a/lib/IPC/Run/Timer.pm b/lib/IPC/Run/Timer.pm index 0550296..828e2b4 100644 --- a/lib/IPC/Run/Timer.pm +++ b/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 diff --git a/lib/IPC/Run/Win32Helper.pm b/lib/IPC/Run/Win32Helper.pm index 74d35e3..3334524 100644 --- a/lib/IPC/Run/Win32Helper.pm +++ b/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 or C and passing it to the child using the command line, the environment, or any other IPC mechanism (it's a plain old integer). diff --git a/t/lib/Test.pm b/t/lib/Test.pm index 307df88..4f9371b 100644 --- a/t/lib/Test.pm +++ b/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" ); }