Spelling corrections in pod/*.pod from Alexandr Savca.
authorAlexandr Savca <alexandr.savca89@gmail.com>
Wed, 18 Apr 2018 20:28:00 +0000 (16:28 -0400)
committerJames E Keenan <jkeenan@cpan.org>
Thu, 19 Apr 2018 13:20:37 +0000 (09:20 -0400)
Alexandr Savca is now a Perl AUTHOR.

For: RT #133120

Committer: holding off on the corrections to pod/perlartistic.pod until
clarification of change to license text.

AUTHORS
pod/perldiag.pod
pod/perlfunc.pod
pod/perlport.pod
pod/perlre.pod
pod/perlrebackslash.pod
pod/perlrecharclass.pod
pod/perlref.pod
pod/perlsec.pod
pod/perlsyn.pod
pod/perlunicode.pod

diff --git a/AUTHORS b/AUTHORS
index adff30b..24ac1b8 100644 (file)
--- a/AUTHORS
+++ b/AUTHORS
@@ -68,6 +68,7 @@ Alexander Klimov              <ask@wisdom.weizmann.ac.il>
 Alexander Smishlajev           <als@turnhere.com>
 Alexander Voronov              <alexander-voronov@yandex.ru>
 Alexandr Ciornii               <alexchorny@gmail.com>
+Alexandr Savca                 <alexandr.savca89@gmail.com>
 Alexandre (Midnite) Jousset    <mid@gtmp.org>
 Alexei Alexandrov              <alexei.alexandrov@gmail.com>
 Alexey Mahotkin                        <alexm@netli.com>
index ca8c9b8..a64157d 100644 (file)
@@ -3899,7 +3899,7 @@ See L<perlfunc/pack>.
 
 (F) Transliteration (C<tr///> and C<y///>) transliterates individual
 characters.  But a named sequence by definition is more than an
-individual charater, and hence doing this operation on it doesn't make
+individual character, and hence doing this operation on it doesn't make
 sense.
 
 =item "my sub" not yet implemented
@@ -4273,7 +4273,7 @@ find out what kind of ref it really was.  See L<perlref>.
 =item '#' not allowed immediately following a sigil in a subroutine signature
 
 (F) In a subroutine signature definition, a comment following a sigil
-(C<$>, C<@> or C<%>), needs to be separated by whitespace or a commma etc., in
+(C<$>, C<@> or C<%>), needs to be separated by whitespace or a comma etc., in
 particular to avoid confusion with the C<$#> variable.  For example:
 
     # bad
index d505bc2..2765a36 100644 (file)
@@ -9394,7 +9394,7 @@ want a version of Perl older than the specified one.
 Specifying VERSION as a numeric argument of the form 5.024001 should
 generally be avoided as older less readable syntax compared to
 v5.24.1. Before perl 5.8.0 released in 2002 the more verbose numeric
-orm was the only supported syntax, which is why you might see it in
+form was the only supported syntax, which is why you might see it in
 
     use v5.24.1;    # compile time version check
     use 5.24.1;     # ditto
index 45158d5..5ad2ffc 100644 (file)
@@ -436,7 +436,7 @@ too).  The portable idiom to remove all the versions of a file is
 
     1 while unlink "file";
 
-This will terminate if the file is undeleteable for some reason
+This will terminate if the file is undeletable for some reason
 (protected, not there, and so on).
 
 Don't count on a specific environment variable existing in
@@ -1362,7 +1362,7 @@ where
     Directory and File =~ m|[^\0- "\.\$\%\&:\@\\^\|\177]+|
 
 The default filename translation is roughly C<tr|/.|./|>, swapping dots
-and slahes.
+and slashes.
 
 Note that C<"ADFS::HardDisk.$.File" ne 'ADFS::HardDisk.$.File'> and that
 the second stage of C<$> interpolation in regular expressions will fall
index 0c6ef15..70c53f1 100644 (file)
@@ -192,7 +192,7 @@ want in the set.  You do this by enclosing the list within C<[]> bracket
 characters.  These are called "bracketed character classes" when we are
 being precise, but often the word "bracketed" is dropped.  (Dropping it
 usually doesn't cause confusion.)  This means that the C<"["> character
-is another metacharacter.  It doesn't match anything just by itelf; it
+is another metacharacter.  It doesn't match anything just by itself; it
 is used only to tell Perl that what follows it is a bracketed character
 class.  If you want to match a literal left square bracket, you must
 escape it, like C<"\[">.  The matching C<"]"> is also a metacharacter;
index 4a1c546..01226e6 100644 (file)
@@ -596,7 +596,7 @@ sentence boundary.  C<\b{sb}> works with text designed for
 word-processors which wrap lines
 automatically for display, but hard-coded line boundaries are considered
 to be essentially the ends of text blocks (paragraphs really), and hence
-the ends of sententces.  C<\b{sb}> doesn't do well with text containing
+the ends of sentences.  C<\b{sb}> doesn't do well with text containing
 embedded newlines, like the source text of the document you are reading.
 Such text needs to be preprocessed to get rid of the line separators
 before looking for sentence boundaries.  Some people view this as a bug
index 8c00850..3b5c5b1 100644 (file)
@@ -641,7 +641,7 @@ Examples:
              #  even on an EBCDIC platform.
  [\N{U+27}-\N{U+3F}] # Same. (U+27 is "'", and U+3F is "?")
 
-As the final two examples above show, you can achieve portablity to
+As the final two examples above show, you can achieve portability to
 non-ASCII platforms by using the C<\N{...}> form for the range
 endpoints.  These indicate that the specified range is to be interpreted
 using Unicode values, so C<[\N{U+27}-\N{U+3F}]> means to match
index fa9e033..cf36922 100644 (file)
@@ -868,7 +868,7 @@ Combining that form with C<local> and putting parentheses immediately
 around a hash are forbidden (because it is not clear what they should do):
 
     \local(@array) = foo(); # WRONG
-    \(%hash)       = bar(); # wRONG
+    \(%hash)       = bar(); # WRONG
 
 Assignment to references and non-references may be combined in lists and
 conditional ternary expressions, as long as the values on the right-hand
index bf1c9b4..b210445 100644 (file)
@@ -380,7 +380,7 @@ see which interpreter to run and when the (now-set-id) interpreter turns
 around and reopens the file to interpret it, the file in question may have
 changed, especially if you have symbolic links on your system.
 
-Some Unices, especially more recent ones, are free of this
+Some Unixes, especially more recent ones, are free of this
 inherent security bug.  On such systems, when the kernel passes the name
 of the set-id script to open to the interpreter, rather than using a
 pathname subject to meddling, it instead passes I</dev/fd/3>.  This is a
@@ -430,7 +430,7 @@ in C:
 
 Compile this wrapper into a binary executable and then make I<it> rather
 than your script setuid or setgid.  Note that this wrapper isn't doing
-anything to santitise the execution environment other than ensuring
+anything to sanitise the execution environment other than ensuring
 that a safe path to the script is used.  It only avoids the shebang
 race condition.  It relies on Perl's own features, and on the script
 itself being careful, to make it safe enough to run the script set-id.
index 74e228d..d63108f 100644 (file)
@@ -992,7 +992,7 @@ the form C<!/REGEX/>, C<$foo !~ /REGEX/>, or C<$foo !~ EXPR>.
 A smart match that uses an explicit C<~~> operator, such as C<EXPR ~~ EXPR>.
 
 B<NOTE:> You will often have to use C<$c ~~ $_> because the default case
-uses C<$_ ~~ $c> , which is frequentlythe opposite of what you want.
+uses C<$_ ~~ $c> , which is frequently the opposite of what you want.
 
 =item Z<>4.
 
index 7515b15..9c9111d 100644 (file)
@@ -394,7 +394,7 @@ other.
 
 You may be presented with strings in any of these equivalent forms.
 There is currently nothing in Perl 5 that ignores the differences.  So
-you'll have to specially hanlde it.  The usual advice is to convert your
+you'll have to specially handle it.  The usual advice is to convert your
 inputs to C<NFD> before processing further.
 
 For more detailed information, see L<http://unicode.org/reports/tr15/>.
@@ -1679,7 +1679,7 @@ See L<perlebcdic/Unicode and UTF>.
 
 Because UTF-EBCDIC is so similar to UTF-8, the differences are mostly
 hidden from you; S<C<use utf8>> (and NOT something like
-S<C<use utfebcdic>>) declares the the script is in the platform's
+S<C<use utfebcdic>>) declares the script is in the platform's
 "native" 8-bit encoding of Unicode.  (Similarly for the C<":utf8">
 layer.)