Subpatterns, either delivered as a list-context result or as $1 etc.
are tainted if C<use locale> is in effect, and the subpattern regular
expression contains C<\w> (to match an alphanumeric character), C<\W>
-(non-alphanumeric character), C<\s> (white-space character), or C<\S>
-(non white-space character). The matched-pattern variable, $&, $`
+(non-alphanumeric character), C<\s> (whitespace character), or C<\S>
+(non whitespace character). The matched-pattern variable, $&, $`
(pre-match), $' (post-match), and $+ (last match) are also tainted if
C<use locale> is in effect and the regular expression contains C<\w>,
C<\W>, C<\s>, or C<\S>.
\*/ # Match the closing delimiter.
} []gsx;
- s/^\s*(.*?)\s*$/$1/; # trim white space in $_, expensively
+ s/^\s*(.*?)\s*$/$1/; # trim whitespace in $_, expensively
- for ($variable) { # trim white space in $variable, cheap
+ for ($variable) { # trim whitespace in $variable, cheap
s/^\s+//;
s/\s+$//;
}
which is definitely not what you want.
The other important thing to notice is that, just as in the shell,
-any white space before or after the filename is ignored. This is good,
+any whitespace before or after the filename is ignored. This is good,
because you wouldn't want these to do different things:
open INFO, "<datafile"
This is not a bug, but a feature. Because C<open> mimics the shell in
its style of using redirection arrows to specify how to open the file, it
-also does so with respect to extra white space around the filename itself
+also does so with respect to extra whitespace around the filename itself
as well. For accessing files with naughty names, see
L<"Dispelling the Dweomer">.
The HANDLE argument is a filehandle just as with C<open>. The PATH is
a literal path, one that doesn't pay attention to any greater-thans or
-less-thans or pipes or minuses, nor ignore white space. If it's there,
+less-thans or pipes or minuses, nor ignore whitespace. If it's there,
it's part of the path. The FLAGS argument contains one or more values
derived from the Fcntl module that have been or'd together using the
bitwise "|" operator. The final argument, the MASK, is optional; if
Here's how to use C<sysopen> to emulate the simple C<open> calls we had
before. We'll omit the C<|| die $!> checks for clarity, but make sure
you always check the return values in real code. These aren't quite
-the same, since C<open> will trim leading and trailing white space,
+the same, since C<open> will trim leading and trailing whitespace,
but you'll get the idea.
To open a file for reading:
the functionality of the RE engine.
Suppose that we want to enable a new RE escape-sequence C<\Y|> which
-matches at boundary between white-space characters and non-whitespace
+matches at boundary between whitespace characters and non-whitespace
characters. Note that C<(?=\S)(?<!\S)|(?!\S)(?<=\S)> matches exactly
at these positions, so we want to have each C<\Y|> in the place of the
more complicated version. We can create a module C<customre> to do
OUTPUT:
RETVAL
-There does not need to be white space at the start of the "C<int input>"
+There does not need to be whitespace at the start of the "C<int input>"
line, but it is useful for improving readability. Placing a semi-colon at
-the end of that line is also optional. Any amount and kind of white space
+the end of that line is also optional. Any amount and kind of whitespace
may be placed between the "C<int>" and "C<input>".
Now re-run make to rebuild our new shared library.
You specify the parameters that will be passed into the XSUB on the line(s)
after you declare the function's return value and name. Each input parameter
-line starts with optional white space, and may have an optional terminating
+line starts with optional whitespace, and may have an optional terminating
semicolon.
The list of output parameters occurs at the very end of the function, just
projects / p5sagit/p5-mst-13.2.git / commitdiff