The '~' modifier will strip, from each line in the here-doc, the
same whitespace that appears before the delimiter.
-Newlines will be copied as is, and lines that don't include the
+Newlines will be copied as-is, and lines that don't include the
proper beginning whitespace will cause perl to croak.
For example:
array. So C<$1> is C<${^CAPTURE}[0]>. This is a more efficient equivalent
to code like C<substr($matched_string,$-[0],$+[0]-$-[0])>, and you don't
have to keep track of the C<$matched_string> either. This variable has no
-single character equivalent. Note like the other regex magic variables
+single character equivalent. Note, like the other regex magic variables
the contents of this variable is dynamic, if you wish to store it beyond
the lifetime of the match you must copy it to another array.
-C<%{^CAPTURE}> is the equivalent to C<%+> (ie named captures). Other than
+C<%{^CAPTURE}> is the equivalent to C<%+> (I<i.e.>, named captures). Other than
being more self documenting there is no difference between the two forms.
-C<%{^CAPTURE_ALL}> is the equivalent to C<%-> (ie all named captures).
+C<%{^CAPTURE_ALL}> is the equivalent to C<%-> (I<i.e.>, all named captures).
Other than being more self documenting there is no difference between the
two forms.
=head2 Better locale collation of strings containing embedded C<NUL>
characters
-In locales that have multi-level character weights, these are now
+In locales that have multi-level character weights, C<NUL>s are now
ignored at the higher priority ones. There are still some gotchas in
some strings, though. See
L<perllocale/Collation of strings containing embedded C<NUL> characters>.
lacks it.
Various toolchain modules will set C<PERL_USE_UNSAFE_INC=1>
-themselves. E.g. L<Test::Harness> sets it since loading modules from a
+themselves. For example, L<Test::Harness> sets it, since loading modules from a
relative path is a common idiom in test code. If you find that you
have C<.> in C<@INC> on a perl built with default settings it's likely
that your code is being invoked by a toolchain module of some sort.
then C<.> will be automatically appended to C<@INC> (except under tainting).
This allows you restore the old perl interpreter behaviour on a
-case-by-case basis. But note that this intended to be a temporary crutch,
+case-by-case basis. But note that this is intended to be a temporary crutch,
and this feature will likely be removed in some future perl version.
It is currently set by the C<cpan> utility and C<Test::Harness> to
-ease installation of CPAN modules which have not been updated handle the
+ease installation of CPAN modules which have not been updated to handle the
lack of dot. Once again, don't use this unless you are sure that this
will not reintroduce any security concerns.
modules), then you have two main options. Firstly, if you are confident
that your script will only be run within a trusted directory (under which
you expect to find trusted files and modules), then add C<.> back into the
-path; e.g.:
+path; I<e.g.>:
BEGIN {
my $dir = "/some/trusted/directory";
=item *
-A hash in boolean context is now sometimes faster, e.g.
+A hash in boolean context is now sometimes faster, I<e.g.>
if (!%h) { ... }
=item *
-Array and hash assignment are now faster, e.g.
+Array and hash assignment are now faster, I<e.g.>
(..., @a) = (...);
(..., %h) = (...);
attempt to fix the bug again in a way that is compatible with VS2015.
These changes do not affect compilation with GCC or with Visual Studio versions
-up to and including VS2013, i.e. the bug fix is retained (unchanged) for those
+up to and including VS2013, I<i.e.>, the bug fix is retained (unchanged) for those
compilers.
Note that you may experience compatibility problems if you mix a perl built
perl built with VS2015 with XS modules built with GCC or VS E<lt>= VS2013.
Some incompatibility may arise because of the bug fix that has been reverted
for VS2015 builds of perl, but there may well be incompatibility anyway because
-of the rewritten CRT in VS2015 (e.g. see discussion at
+of the rewritten CRT in VS2015 (I<e.g.>, see discussion at
http://stackoverflow.com/questions/30412951).
=back
=item *
Since 5.24.0 in some obscure cases, a regex which included code blocks
-from multiple sources (e.g. via embedded via qr// objects) could end up
+from multiple sources (I<e.g.>, via embedded via qr// objects) could end up
with the wrong current pad and crash or give weird results. [perl #129881]
=item *
=item *
-A sub containing a "forward" declaration with the same name (e.g.,
+A sub containing a "forward" declaration with the same name (I<e.g.>,
C<sub c { sub c; }>) could sometimes crash or loop infinitely. [perl
#129090]
=item *
-Invalid assignments to a reference constructor (e.g., C<\eval=time>) could
+Invalid assignments to a reference constructor (I<e.g.>, C<\eval=time>) could
sometimes crash in addition to giving a syntax error. [perl #125679]
=item *
=item *
-A sub containing with a "forward" declaration with the same name (e.g.,
+A sub containing with a "forward" declaration with the same name
+(I<e.g.>,
C<sub c { sub c; }>) could sometimes crash or loop infinitely. [perl
#129090]
=item *
-Vivifying a subroutine stub in a deleted stash (e.g., C<delete $My::{"Foo::"};
+Vivifying a subroutine stub in a deleted stash (I<e.g.>, C<delete $My::{"Foo::"};
\&My::Foo::foo>) no longer crashes. It had begun crashing in Perl 5.18.
L<[perl #128532]|https://rt.perl.org/Public/Bug/Display.html?id=128532>
=item *
Fixed an assertion triggered by some code that handles deprecated behavior in
-formats, e.g. in cases like this:
+formats, I<e.g.>, in cases like this:
format STDOUT =
@
https://perl5.git.perl.org / perl5.git / commitdiff