These are all in the pod/ directory, and only the first is a code fix.
There was also a single lingering ISO 8859-1 encoding that missed the
UTF-8 upconvert. The rest are cleanups for typos, some of which seem
to have been around for a rather long time: spelling errors, incorrect
possessives, and extra, missing, or duplicated words.
If you actually read through, I bet you'll realize what sparked this. :)
--tom
Signed-off-by: Abigail <abigail@abigail.be>
rename $name, "$name.old" or die "$0: Can't rename $name to $name.old: $!";
open THING, ">$name" or die "$0: Can't open $name for writing: $!";
print THING $new or die "$0: print to $name failed: $!";
- close THING or die die "$0: close $name failed: $!";
+ close THING or die "$0: close $name failed: $!";
}
warn "$0: was not instructed to build anything\n" unless $built;
=head2 kill() on Windows
On Windows platforms, C<kill(-9, $pid)> now kills a process tree.
-(On UNIX, this delivers the signal to all processes in the same process
+(On Unix, this delivers the signal to all processes in the same process
group.)
=head1 Incompatible Changes
=head2 Elimination of SVt_PVBM
-Related to this, the internal type C<SVt_PVBM> has been been removed. This
+Related to this, the internal type C<SVt_PVBM> has been removed. This
dedicated type of C<SV> was used by the C<index> operator and parts of the
regexp engine to facilitate fast Boyer-Moore matches. Its use internally has
been replaced by C<SV>s of type C<SVt_PVGV>.
=item *
-On some UNIX systems, the value in C<$?> would not have the top bit set
+On some Unix systems, the value in C<$?> would not have the top bit set
(C<$? & 128>) even if the child core dumped.
=item *
=item *
-On some UNIX systems, the value in C<$?> would not have the top bit set
+On some Unix systems, the value in C<$?> would not have the top bit set
(C<$? & 128>) even if the child core dumped.
=item *
=item *
-Smart match against C<@_> sometimes gave false negatives negatives. [perl #71078]
+Smart match against C<@_> sometimes gave false negatives. [perl #71078]
=item *
=item *
The perlcc utility has been rewritten and its user interface (that is,
-command line) is much more like that of the UNIX C compiler, cc.
+command line) is much more like that of the Unix C compiler, cc.
=item *
previous Perls), perlio (re-implementation of stdio buffering in a
portable manner), crlf (does CRLF <=> "\n" translation as on Win32,
but available on any platform). A mmap layer may be available if
-platform supports it (mostly UNIXes).
+platform supports it (mostly Unixes).
Layers to be applied by default may be specified via the 'open' pragma.
=item *
-The list form of C<open> is now implemented for pipes (at least on UNIX):
+The list form of C<open> is now implemented for pipes (at least on Unix):
open($fh,"-|", 'cat', '/etc/motd')
=item *
-The Amdahl UTS UNIX mainframe platform is now supported.
+The Amdahl UTS Unix mainframe platform is now supported.
=back
L<Changes58> (or L<Changes> in Perl 5.8.1). In addition to these
changes, lots of work took place in integrating threads, PerlIO, and
Unicode; general code cleanup; and last but not least porting to
-non-UNIX lands such as Win32, VMS, Cygwin, DJGPP, VOS, MacOS Classic,
+non-Unix lands such as Win32, VMS, Cygwin, DJGPP, VOS, MacOS Classic,
and EBCDIC.
=over 4
=head1 Installation and Configuration Improvements
-The UNIX standard Perl location, F</usr/bin/perl>, is no longer
+The Unix standard Perl location, F</usr/bin/perl>, is no longer
overwritten by default if it exists. This change was very prudent
-because so many UNIX vendors already provide a F</usr/bin/perl>,
+because so many Unix vendors already provide a F</usr/bin/perl>,
but simultaneously many system utilities may depend on that
exact version of Perl, so better not to overwrite it.
=item *
-Operations that require perl to read a process' list of groups, such as reads
+Operations that require perl to read a process's list of groups, such as reads
of C<$(> and C<$)>, now dynamically allocate memory rather than using a
fixed sized array. The fixed size array could cause C stack exhaustion on
systems configured to use large numbers of groups.
=item *
-now generates correct correct code for C<#if defined A || defined B>
+now generates correct code for C<#if defined A || defined B>
[RT #39130]
=back
=item *
-On VMS, escaped dots will be preserved when converted to UNIX syntax.
+On VMS, escaped dots will be preserved when converted to Unix syntax.
=item *
=item t/op/incfilter.t
-Tests for for source filters returned from code references in C<@INC>.
+Tests for source filters returned from code references in C<@INC>.
=item t/op/kill0.t
The list of filenames from glob() (or <...>) is now by default sorted
alphabetically to be csh-compliant (which is what happened before
-in most UNIX platforms). (bsd_glob() does still sort platform
+in most Unix platforms). (bsd_glob() does still sort platform
natively, ASCII or EBCDIC, unless GLOB_ALPHASORT is specified.) [561]
=head2 Deprecations
previous Perls), perlio (re-implementation of stdio buffering in a
portable manner), crlf (does CRLF <=> "\n" translation as on Win32,
but available on any platform). A mmap layer may be available if
-platform supports it (mostly UNIXes).
+platform supports it (mostly Unixes).
Layers to be applied by default may be specified via the 'open' pragma.
=item *
C<perlcc> has been rewritten and its user interface (that is,
-command line) is much more like that of the UNIX C compiler, cc.
+command line) is much more like that of the Unix C compiler, cc.
(The perlbc tools has been removed. Use C<perlcc -B> instead.)
B<Note that perlcc is still considered very experimental and
unsupported.> [561]
=item *
C<pod2html> now understands POD written using different line endings
-(PC-like CRLF versus UNIX-like LF versus MacClassic-like CR).
+(PC-like CRLF versus Unix-like LF versus MacClassic-like CR).
=item *
=item *
-The Amdahl UTS UNIX mainframe platform is now supported. [561]
+The Amdahl UTS Unix mainframe platform is now supported. [561]
=item *
=head1 Installation and Configuration Improvements
-The UNIX standard Perl location, F</usr/bin/perl>, is no longer
+The Unix standard Perl location, F</usr/bin/perl>, is no longer
overwritten by default if it exists. This change was very prudent
-because so many UNIX vendors already provide a F</usr/bin/perl>,
+because so many Unix vendors already provide a F</usr/bin/perl>,
but simultaneously many system utilities may depend on that
exact version of Perl, so better not to overwrite it.
=item *
-Operations that require perl to read a process' list of groups, such as reads
+Operations that require perl to read a process's list of groups, such as reads
of C<$(> and C<$)>, now dynamically allocate memory rather than using a
fixed sized array. The fixed size array could cause C stack exhaustion on
systems configured to use large numbers of groups.
=head1 Hiding Perl_
-If you completely hide the short forms forms of the Perl public API,
+If you completely hide the short forms of the Perl public API,
add -DPERL_NO_SHORT_NAMES to the compilation flags. This means that
for example instead of writing
The perlfaq comes with the standard Perl distribution, so if you have Perl
you should have the perlfaq. You should also have the C<perldoc> tool
-that let's you read the L<perlfaq>:
+that lets you read the L<perlfaq>:
$ perldoc perlfaq
Tom Christiansen wrote the original perlfaq then expanded it with the
help of Nat Torkington. The perlfaq-workers maintain current document
-and the dezinens of comp.lang.perl.misc regularly review and update the
+and the denizens of comp.lang.perl.misc regularly review and update the
FAQ. Several people have contributed answers, corrections, and comments,
and the perlfaq notes those contributions wherever appropriate.
Copyright (c) 1997-2009 Tom Christiansen, Nathan Torkington, and
other authors as noted. All rights reserved.
-Tom Christainsen wrote the original version of this document.
+Tom Christiansen wrote the original version of this document.
brian d foy C<< <bdfoy@cpan.org> >> wrote this version. See the
individual perlfaq documents for additional copyright information.
=back
-
see their FAQ ( http://www.faqs.org/faqs/alt-sources-intro/ ) for details.
If you're just looking for software, first use Google
-( http://www.google.com ), Google's usenet search interface
+( http://www.google.com ), Google's USENET search interface
( http://groups.google.com ), and CPAN Search ( http://search.cpan.org ).
This is faster and more productive than just posting a request.
Perl programs are just plain text, so any editor will do.
-If you're on Unix, you already have an IDE--Unix itself. The UNIX
+If you're on Unix, you already have an IDE--Unix itself. The Unix
philosophy is the philosophy of several small tools that each do one
thing and do it well. It's like a carpenter's toolbox.
nvi ( http://www.bostic.com/vi/ , available from CPAN in src/misc/) is
yet another vi clone, unfortunately not available for Windows, but in
-UNIX platforms you might be interested in trying it out, firstly because
+Unix platforms you might be interested in trying it out, firstly because
strictly speaking it is not a vi clone, it is the real vi, or the new
incarnation of it, and secondly because you can embed Perl inside it
to use Perl as the scripting language. nvi is not alone in this,
research purposes), Cygwin is covered by the GNU General Public
License (but that shouldn't matter for Perl use). The Cygwin, MKS,
and U/WIN all contain (in addition to the shells) a comprehensive set
-of standard UNIX toolkit utilities.
+of standard Unix toolkit utilities.
If you're transferring text files between Unix and Windows using FTP
be sure to transfer them in ASCII mode so the ends of lines are
Perl2Exe ( http://www.indigostar.com/perl2exe.htm ) is a command line
program for converting perl scripts to executable files. It targets both
-Windows and unix platforms.
+Windows and Unix platforms.
=head2 How can I get C<#!perl> to work on [MS-DOS,NT,...]?
The C<ExtUtils::MakeMaker> module, better known simply as "MakeMaker",
turns a Perl script, typically called C<Makefile.PL>, into a Makefile.
-The unix tool C<make> uses this file to manage dependencies and actions
+The Unix tool C<make> uses this file to manage dependencies and actions
to process and install a Perl distribution.
=head1 REVISION
print $string + 44; # prints 688, certainly not octal!
This problem usually involves one of the Perl built-ins that has the
-same name a unix command that uses octal numbers as arguments on the
+same name a Unix command that uses octal numbers as arguments on the
command line. In this example, C<chmod> on the command line knows that
its first argument is octal because that's what it does:
(contributed by brian d foy)
-Perl itself never had a Y2K problem, although that nevers stopped people
+Perl itself never had a Y2K problem, although that never stopped people
from creating Y2K problems on their own. See the documentation for
C<localtime> for its proper use.
Calling a subroutine as C<&foo> with no trailing parentheses ignores
the prototype of C<foo> and passes it the current value of the argument
list, C<@_>. Here's an example; the C<bar> subroutine calls C<&foo>,
-which prints what its arguments list:
+which prints its argument list:
sub bar { &foo }
However, using the code requires that you have a working C compiler
and can use it to build and install a CPAN module. Here's a solution
-using the standard C<POSIX> module, which is already on your systems
+using the standard C<POSIX> module, which is already on your system
(assuming your system supports POSIX).
use HotKey;
C<Proc::Background>, and C<Win32::Process>. There are many other modules you
might use, so check those namespaces for other options too.
-If you are on a unix-like system, you might be able to get away with a
+If you are on a Unix-like system, you might be able to get away with a
system call where you put an C<&> on the end of the command:
system("cmd &")
However, if all you want to do is change your time zone, you can
probably get away with setting an environment variable:
- $ENV{TZ} = "MST7MDT"; # unixish
+ $ENV{TZ} = "MST7MDT"; # Unixish
$ENV{'SYS$TIMEZONE_DIFFERENTIAL'}="-5" # vms
system "trn comp.lang.perl.misc";
=head2 Why can't my script read from STDIN after I gave it EOF (^D on Unix, ^Z on MS-DOS)?
This happens only if your perl is compiled to use stdio instead of
-perlio, which is the default. Some (maybe all?) stdio's set error and
+perlio, which is the default. Some (maybe all?) stdios set error and
eof flags that you may need to clear. The C<POSIX> module defines
C<clearerr()> that you can use. That is the technically correct way to
do it. Here are some less reliable workarounds:
the salt, followed by 11 bytes from the set C<[./0-9A-Za-z]>, and only
the first eight bytes of PLAINTEXT mattered. But alternative
hashing schemes (like MD5), higher level security schemes (like C2),
-and implementations on non-UNIX platforms may produce different
+and implementations on non-Unix platforms may produce different
strings.
When choosing a new salt create a random two character string whose
either read-write mode for updating textfiles, since they have
variable length records. See the B<-i> switch in L<perlrun> for a
better approach. The file is created with permissions of C<0666>
-modified by the process' C<umask> value.
+modified by the process's C<umask> value.
These various prefixes correspond to the fopen(3) modes of C<'r'>,
C<'r+'>, C<'w'>, C<'w+'>, C<'a'>, and C<'a+'>.
Note that if you are using Perls older than 5.8.0, Perl will be using
the standard C libraries' fdopen() to implement the "=" functionality.
-On many UNIX systems fdopen() fails when file descriptors exceed a
+On many Unix systems fdopen() fails when file descriptors exceed a
certain value, typically 255. For Perls 5.8.0 and later, PerlIO is
most often the default.
The last example in each block shows the pipe as "list form", which is
not yet supported on all platforms. A good rule of thumb is that if
your platform has true C<fork()> (in other words, if your platform is
-UNIX) you can use the list form.
+Unix) you can use the list form.
See L<perlipc/"Safe Pipe Opens"> for more examples of this.
still seen in older code).
If VERSION is provided, C<package> also sets the C<$VERSION> variable in the
-given namespace. VERSION must be be a numeric literal or v-string; it is
+given namespace. VERSION must be a numeric literal or v-string; it is
parsed exactly the same way as a VERSION argument to C<use MODULE VERSION>.
C<$VERSION> should only be set once per package.
the function whose prototype you want to retrieve.
If FUNCTION is a string starting with C<CORE::>, the rest is taken as a
-name for Perl builtin. If the builtin is not I<overridable> (such as
+name for a Perl builtin. If the builtin is not I<overridable> (such as
C<qw//>) or if its arguments cannot be adequately expressed by a prototype
(such as C<system>), prototype() returns C<undef>, because the builtin
does not really behave like a Perl function. Otherwise, the string
empty. If it succeeds it returns true, otherwise it returns false and
sets C<$!> (errno). If FILENAME is omitted, uses C<$_>.
-To remove a directory tree recursively (C<rm -rf> on unix) look at
+To remove a directory tree recursively (C<rm -rf> on Unix) look at
the C<rmtree> function of the L<File::Path> module.
=item s///
on this.
Note that C<sysopen> depends on the fdopen() C library function.
-On many UNIX systems, fdopen() is known to fail when file descriptors
+On many Unix systems, fdopen() is known to fail when file descriptors
exceed a certain value, typically 255. If you need more file
descriptors than that, consider rebuilding Perl to use the C<sfio>
library, or perhaps using the POSIX::open() function.
portability of the core code rests with the Configure pumpkin -
others help out with individual operating systems.
-The three files that fall under his/her resposibility are Configure,
+The three files that fall under his/her responsibility are Configure,
config_h.SH, and Porting/Glossary (and a whole bunch of small related
files that are less important here). The Configure pumpkin decides how
patches to these are dealt with. Currently, the Configure pumpkin will
#endif
How does the HAS_QUUX become defined where it needs to be? Well, if
-Foonix happens to be UNIXy enough to be able to run the Configure
+Foonix happens to be Unixy enough to be able to run the Configure
script, and Configure has been taught about detecting and testing
quux(), the HAS_QUUX will be correctly defined. In other platforms,
the corresponding configuration step will hopefully do the same.
PERL_DESTRUCT_LEVEL=2
export PERL_DESTRUCT_LEVEL
-or in UNIXy environments you can also use the C<env> command:
+or in Unixy environments you can also use the C<env> command:
env PERL_DESTRUCT_LEVEL=2 valgrind ./perl -Ilib ...
=head2 Gprof Profiling
-gprof is a profiling tool available in many UNIX platforms,
+gprof is a profiling tool available in many Unix platforms,
it uses F<statistical time-sampling>.
You can build a profiled version of perl called "perl.gprof" by
order.
sysopen() operates (unsurprisingly) at a lower level in the stack than
-open(). For example in UNIX or UNIX-like systems sysopen() operates
+open(). For example in Unix or Unix-like systems sysopen() operates
directly at the level of file descriptors: in the terms of PerlIO
layers, it uses only the "unix" layer, which is a rather thin wrapper
-on top of the UNIX file descriptors.
+on top of the Unix file descriptors.
=head2 Layers vs Disciplines
Unread PerlIOBase_unread
Write FAILURE
- FAILURE Set errno (to EINVAL in UNIXish, to LIB$_INVARG in VMS) and
+ FAILURE Set errno (to EINVAL in Unixish, to LIB$_INVARG in VMS) and
return -1 (for numeric return values) or NULL (for pointers)
INHERITED Inherited from the layer below
SUCCESS Return 0 (for numeric return values) or a pointer
never exit. A single process closing a pipe is not enough to close it;
the last process with the pipe open must close it for it to read EOF.
-There are some features built-in to unix to help prevent this most of
+Certain built-in Unix features help prevent this most of
the time. For instance, filehandles have a 'close on exec' flag (set
I<en masse> with Perl using the C<$^F> L<perlvar>), so that any
filehandles which you didn't explicitly route to the STDIN, STDOUT or
=head2 I18N::Langinfo
Another interface for querying locale-dependent information is the
-I18N::Langinfo::langinfo() function, available at least in UNIX-like
+I18N::Langinfo::langinfo() function, available at least in Unix-like
systems and VMS.
The following example will import the langinfo() function itself and
B<NOTE>: C<LANGUAGE> is a GNU extension, it affects you only if you
are using the GNU libc. This is the case if you are using e.g. Linux.
-If you are using "commercial" UNIXes you are most probably I<not>
+If you are using "commercial" Unixes you are most probably I<not>
using GNU libc and you can ignore C<LANGUAGE>.
However, in the case you are using C<LANGUAGE>: it affects the
L<perlmod>, L<perlmodlib>, L<perlmodinstall>, L<h2xs>, L<strict>,
L<Carp>, L<Exporter>, L<perlpod>, L<Test::Simple>, L<Test::More>
L<ExtUtils::MakeMaker>, L<Module::Build>, L<Module::Starter>
-http://www.cpan.org/ , Ken Williams' tutorial on building your own
+http://www.cpan.org/ , Ken Williams's tutorial on building your own
module at http://mathforum.org/~ken/perl_modules.html
Why so permissive? Well, it isn't really. The MASK will be modified
by your process's current C<umask>. A umask is a number representing
I<disabled> permissions bits; that is, bits that will not be turned on
-in the created files' permissions field.
+in the created file's permissions field.
For example, if your C<umask> were 027, then the 020 part would
disable the group from writing, and the 007 part would disable others
Firstly, you need to establish a baseline time for the existing code, which
timing needs to be reliable and repeatable. You'll probably want to use the
C<Benchmark> or C<Devel::DProf> modules, or something similar, for this step,
-or perhaps the unix system C<time> utility, whichever is appropriate. See the
+or perhaps the Unix system C<time> utility, whichever is appropriate. See the
base of this document for a longer list of benchmarking and profiling modules,
and recommended further reading.
direct approach managed to run an additional 204,403 times, unfortunately.
Unfortunately, because there are many examples of code written using the
multiple layer direct variable access, and it's usually horrible. It is,
-however, miniscully faster. The question remains whether the minute gain is
+however, minusculy faster. The question remains whether the minute gain is
actually worth the eyestrain, or the loss of maintainability.
=head2 Search and replace or tr
tr: 0 wallclock secs ( 0.49 usr + 0.00 sys = 0.49 CPU) @ 2040816.33/s (n=1000000)
The C<tr> version is a clear winner. One solution is flexible, the other is
-fast - and it's appropriately the programmers choice which to use in the
-circumstances.
+fast - and it's appropriately the programmer's choice which to use.
Check the C<Benchmark> docs for further useful techniques.
Interestingly we get slightly different results, which is mostly because the
algorithm which generates the report is different, even though the output file
format was allegedly identical. The elapsed, user and system times are clearly
-showing the time it took for C<Devel::Profiler> to execute it's own run, but
+showing the time it took for C<Devel::Profiler> to execute its own run, but
the column listings feel more accurate somehow than the ones we had earlier
from C<Devel::DProf>. The 102% figure has disappeared, for example. This is
where we have to use the tools at our disposal, and recognise their pros and
C<NYTProf> will generate a report database into the file F<nytprof.out> by
default. Human readable reports can be generated from here by using the
supplied C<nytprofhtml> (HTML output) and C<nytprofcsv> (CSV output) programs.
-We've used the unix sytem C<html2text> utility to convert the
+We've used the Unix sytem C<html2text> utility to convert the
F<nytprof/index.html> file for convenience here.
$> html2text nytprof/index.html
A command such as this can vastly reduce the volume of material to actually
sort through in the first place, and should not be too lightly disregarded
-purely on the basis of it's simplicity. The C<KISS> principle is too often
+purely on the basis of its simplicity. The C<KISS> principle is too often
overlooked - the next example uses the simple system C<time> utility to
demonstrate. Let's take a look at an actual example of sorting the contents of
a large file, an apache logfile would do. This one has over a quarter of a
The time has been cut in half, which is a respectable speed improvement by any
standard. Naturally, it is important to check the output is consistent with
-the first program run, this is where the unix system C<cksum> utility comes in.
+the first program run, this is where the Unix system C<cksum> utility comes in.
$> cksum out-sort out-schwarz
3044173777 52029194 out-sort
Link to a Perl manual page (e.g., C<LE<lt>Net::PingE<gt>>). Note
that C<name> should not contain spaces. This syntax
-is also occasionally used for references to UNIX man pages, as in
+is also occasionally used for references to Unix man pages, as in
C<LE<lt>crontab(5)E<gt>>.
=item *
At time of writing, C<LE<lt>nameE<gt>> values are of two types:
either the name of a Pod page like C<LE<lt>Foo::BarE<gt>> (which
might be a real Perl module or program in an @INC / PATH
-directory, or a .pod file in those places); or the name of a UNIX
+directory, or a .pod file in those places); or the name of a Unix
man page, like C<LE<lt>crontab(5)E<gt>>. In theory, C<LE<lt>chmodE<gt>>
in ambiguous between a Pod page called "chmod", or the Unix man page
"chmod" (in whatever man-section). However, the presence of a string
in parens, as in "crontab(5)", is sufficient to signal that what
is being discussed is not a Pod page, and so is presumably a
-UNIX man page. The distinction is of no importance to many
+Unix man page. The distinction is of no importance to many
Pod processors, but some processors that render to hypertext formats
may need to distinguish them in order to know how to render a
given C<LE<lt>fooE<gt>> code.
(e.g. the FAT filesystem limits the time granularity to two seconds).
The "inode change timestamp" (the C<-C> filetest) may really be the
-"creation timestamp" (which it is not in UNIX).
+"creation timestamp" (which it is not in Unix).
VOS perl can emulate Unix filenames with C</> as path separator. The
native pathname characters greater-than, less-than, number-sign, and
separator, or go native and use C<.> for path separator and C<:> to
signal filesystems and disk names.
-Don't assume UNIX filesystem access semantics: that read, write,
+Don't assume Unix filesystem access semantics: that read, write,
and execute are all the permissions there are, and even if they exist,
that their semantics (for example what do r, w, and x mean on
-a directory) are the UNIX ones. The various UNIX/POSIX compatibility
+a directory) are the Unix ones. The various Unix/POSIX compatibility
layers usually try to make interfaces like chmod() work, but sometimes
there simply is no good mapping.
under so that you can write code explicitly for that platform (or
class of platforms).
-Don't assume the UNIX filesystem access semantics: the operating
+Don't assume the Unix filesystem access semantics: the operating
system or the filesystem may be using some ACL systems, which are
richer languages than the usual rwx. Even if the rwx exist,
their semantics might be different.
permissions between the permissions check and the actual operation.
Just try the operation.)
-Don't assume the UNIX user and group semantics: especially, don't
+Don't assume the Unix user and group semantics: especially, don't
expect the C<< $< >> and C<< $> >> (or the C<$(> and C<$)>) to work
for switching identities (or memberships).
shell or file parsing utilities need to be prefixed with the C<^>
character, or replaced with hexadecimal characters prefixed with the
C<^> character. Such prefixing is only needed with the pathnames are
-in VMS format in applications. Programs that can accept the UNIX format
+in VMS format in applications. Programs that can accept the Unix format
of pathnames do not need the escape characters. The maximum length for
filenames is 255 characters. The ODS-5 file system can handle both
a case preserved and a case sensitive mode.
settings to preserve backward compatibility with Perl scripts that
assume the previous VMS limitations.
-In general routines on VMS that get a UNIX format file specification
-should return it in a UNIX format, and when they get a VMS format
+In general routines on VMS that get a Unix format file specification
+should return it in a Unix format, and when they get a VMS format
specification they should return a VMS format unless they are documented
to do a conversion.
For routines that generate return a file specification, VMS allows setting
if the C library which Perl is built on if it will be returned in VMS
-format or in UNIX format.
+format or in Unix format.
With the ODS-2 file system, there is not much difference in syntax of
-filenames without paths for VMS or UNIX. With the extended character
+filenames without paths for VMS or Unix. With the extended character
set available with ODS-5 there can be a significant difference.
Because of this, existing Perl scripts written for VMS were sometimes
-treating VMS and UNIX filenames interchangeably. Without the extended
+treating VMS and Unix filenames interchangeably. Without the extended
character set enabled, this behavior will mostly be maintained for
backwards compatibility.
When extended characters are enabled with ODS-5, the handling of
-UNIX formatted file specifications is to that of a UNIX system.
+Unix formatted file specifications is to that of a Unix system.
VMS file specifications without extensions have a trailing dot. An
-equivalent UNIX file specification should not show the trailing dot.
+equivalent Unix file specification should not show the trailing dot.
The result of all of this, is that for VMS, for portable scripts, you
can not depend on Perl to present the filenames in lowercase, to be
case sensitive, and that the filenames could be returned in either
-UNIX or VMS format.
+Unix or VMS format.
And if a routine returns a file specification, unless it is intended to
convert it, it should return it in the same format as it found it.
C<open(FH, 'A')>).
With support for extended file specifications and if C<opendir> was
-given a UNIX format directory, a file named F<A.;5> will return F<a>
+given a Unix format directory, a file named F<A.;5> will return F<a>
and optionally in the exact case on the disk. When C<opendir> is given
a VMS format directory, then C<readdir> should return F<a.>, and
again with the optionally the exact case.
=item exit
-Emulates UNIX exit() (which considers C<exit 1> to indicate an error) by
+Emulates Unix exit() (which considers C<exit 1> to indicate an error) by
mapping the C<1> to SS$_ABORT (C<44>). This behavior may be overridden
with the pragma C<use vmsish 'exit'>. As with the CRTL's exit()
function, C<exit 0> is also mapped to an exit status of SS$_NORMAL
=item sockatmark
A relatively recent addition to socket functions, may not
-be implemented even in UNIX platforms.
+be implemented even in Unix platforms.
=item socketpair
forbidden.
Any pattern containing a special backtracking verb that allows an argument
-has the special behaviour that when executed it sets the current packages'
+has the special behaviour that when executed it sets the current package's
C<$REGERROR> and C<$REGMARK> variables. When doing so the following
rules apply:
this document are expected to understand perl's regex syntax and its
usage in detail. If you want to learn about the basics of Perl's
regular expressions, see L<perlre>. And if you want to replace the
-regex engine with your own see see L<perlreapi>.
+regex engine with your own, see L<perlreapi>.
=head1 OVERVIEW
=item *
There is the "next regop" from a given regop/regnode. This is the
-regop physically located after the the current one, as determined by
+regop physically located after the current one, as determined by
the size of the current regop. This is often useful, such as when
dumping the structure we use this order to traverse. Sometimes the code
assumes that the "next regnode" is the same as the "next regop", or in
The two entry points are C<re_intuit_start()> and C<pregexec()>. These routines
have a somewhat incestuous relationship with overlap between their functions,
and C<pregexec()> may even call C<re_intuit_start()> on its own. Nevertheless
-other parts of the the perl source code may call into either, or both.
+other parts of the perl source code may call into either, or both.
Execution of the interpreter itself used to be recursive, but thanks to the
efforts of Dave Mitchell in the 5.9.x development track, that has changed: now an
internal stack is maintained on the heap and the routine is fully
iterative. This can make it tricky as the code is quite conservative
-about what state it stores, with the result that that two consecutive lines in the
+about what state it stores, with the result that two consecutive lines in the
code can actually be running in totally different contexts due to the
simulated recursion.
the regexp engine proceeds according to the book: as long as the end of
the string hasn't been reached, the position is advanced before looking
for another vowel. Thus, match or no match makes no difference, and the
-regexp engine proceeds until the the entire string has been inspected.
+regexp engine proceeds until the entire string has been inspected.
(It's remarkable that an alternative solution using something like
$count{lc($_)}++ for split('', "supercalifragilisticexpialidoceous");
$ perl -pi~ -e 's/foo/bar/' file1 file2 file3...
Note that because B<-i> renames or deletes the original file before
-creating a new file of the same name, UNIX-style soft and hard links will
+creating a new file of the same name, Unix-style soft and hard links will
not be preserved.
Finally, the B<-i> switch does not impede execution when no
being done at interpreter startup time.)
If PERL5LIB is not defined, PERLLIB is used. Directories are separated
-(like in PATH) by a colon on unixish platforms and by a semicolon on
+(like in PATH) by a colon on Unixish platforms and by a semicolon on
Windows (the proper path separator being given by the command C<perl
-V:path_sep>).
environment variable) treats the colon as a separator.
An unset or empty PERLIO is equivalent to the default set of layers for
-your platform, for example C<:unix:perlio> on UNIX-like systems
+your platform, for example C<:unix:perlio> on Unix-like systems
and C<:unix:crlf> on Windows and other DOS-like systems.
The list becomes the default for I<all> perl's IO. Consequently only built-in
On all platforms the default set of layers should give acceptable results.
-For UNIX platforms that will equivalent of "unix perlio" or "stdio".
+For Unix platforms that will equivalent of "unix perlio" or "stdio".
Configure is setup to prefer "stdio" implementation if system's library
provides for fast access to the buffer, otherwise it uses the "unix perlio"
implementation.
If set to the name of a file or device then certain operations of PerlIO
sub-system will be logged to that file (opened as append). Typical uses
-are UNIX:
+are Unix:
PERLIO_DEBUG=/dev/tty perl script ...
is that by default, no data is shared. When a new Perl thread is created,
all the data associated with the current thread is copied to the new
thread, and is subsequently private to that new thread!
-This is similar in feel to what happens when a UNIX process forks,
+This is similar in feel to what happens when a Unix process forks,
except that in this case, the data is just copied to a different part of
memory within the same process rather than a real fork taking place.
establishing quotas. Say, for example, that you have a number of
threads that can do I/O at once. You don't want all the threads
reading or writing at once though, since that can potentially swamp
-your I/O channels, or deplete your process' quota of filehandles. You
+your I/O channels, or deplete your process's quota of filehandles. You
can use a semaphore initialized to the number of concurrent I/O
requests (or open files) that you want at any one time, and have your
threads quietly block and unblock themselves.
Thinking of mixing C<fork()> and threads? Please lie down and wait
until the feeling passes. Be aware that the semantics of C<fork()> vary
-between platforms. For example, some UNIX systems copy all the current
+between platforms. For example, some Unix systems copy all the current
threads into the child process, while others only copy the thread that
called C<fork()>. You have been warned!
Slightly modified by Arthur Bergman to fit the new thread model/module.
-Reworked slightly by Jˆrg Walter E<lt>jwalt@cpan.org<gt> to be more concise
+Reworked slightly by Jörg Walter E<lt>jwalt@cpan.org<gt> to be more concise
about thread-safety of Perl code.
Rearranged slightly by Elizabeth Mattijsen E<lt>liz@dijkmat.nl<gt> to put
=head2 Improve the coverage of the core tests
-Use Devel::Cover to ascertain the core modules's test coverage, then add
+Use Devel::Cover to ascertain the core modules' test coverage, then add
tests that are currently missing.
=head2 test B
This has actually already been implemented (but only for Win32),
take a look at F<iperlsys.h> and F<win32/perlhost.h>. While all Win32
variants go through a set of "vtables" for operating system access,
-non-Win32 systems currently go straight for the POSIX/UNIX-style
+non-Win32 systems currently go straight for the POSIX/Unix-style
system/library call. Similar system as for Win32 should be
implemented for all platforms. The existing Win32 implementation
probably does not need to survive alongside this proposed new
=item L<prove>
-F<prove> is a command-line interface to the test-running functionality of
+F<prove> is a command-line interface to the test-running functionality
of F<Test::Harness>. It's an alternative to C<make test>.
=item L<corelist>
routine to force it to that format.
The feature logical name DECC$FILENAME_UNIX_REPORT modifies traditional
-Perl behavior in the conversion of file specifications from UNIX to VMS
+Perl behavior in the conversion of file specifications from Unix to VMS
format in order to follow the extended character handling rules now
expected by the CRTL. Specifically, when this feature is in effect, the
-C<./.../> in a UNIX path is now translated to C<[.^.^.^.]> instead of
+C<./.../> in a Unix path is now translated to C<[.^.^.^.]> instead of
the traditional VMS C<[...]>. To be compatible with what MakeMaker
-expects, if a VMS path cannot be translated to a UNIX path, it is
+expects, if a VMS path cannot be translated to a Unix path, it is
passed through unchanged, so C<unixify("[...]")> will return C<[...]>.
The handling of extended characters is largely complete in the
directories containing some extended characters.
There are several ambiguous cases where a conversion routine cannot
-determine whether an input filename is in UNIX format or in VMS format,
-since now both VMS and UNIX file specifications may have characters in
+determine whether an input filename is in Unix format or in VMS format,
+since now both VMS and Unix file specifications may have characters in
them that could be mistaken for syntax delimiters of the other type. So
some pathnames simply cannot be used in a mode that allows either type
of pathname to be present. Perl will tend to assume that an ambiguous
-filename is in UNIX format.
+filename is in Unix format.
Allowing "." as a version delimiter is simply incompatible with
-determining whether a pathname is in VMS format or in UNIX format with
+determining whether a pathname is in VMS format or in Unix format with
extended file syntax. There is no way to know whether "perl-5.8.6" is a
-UNIX "perl-5.8.6" or a VMS "perl-5.8;6" when passing it to unixify() or
+Unix "perl-5.8.6" or a VMS "perl-5.8;6" when passing it to unixify() or
vmsify().
The DECC$FILENAME_UNIX_REPORT logical name controls how Perl interprets
filenames to the extent that Perl uses the CRTL internally for many
purposes, and attempts to follow CRTL conventions for reporting
filenames. The DECC$FILENAME_UNIX_ONLY feature differs in that it
-expects all filenames passed to the C run-time to be already in UNIX
+expects all filenames passed to the C run-time to be already in Unix
format. This feature is not yet supported in Perl since Perl uses
traditional OpenVMS file specifications internally and in the test
harness, and it is not yet clear whether this mode will be useful or
in the filesystem and CRTL (generally 64-bit OpenVMS v8.3 and later).
There are a number of limitations and caveats to be aware of when
working with symbolic links on VMS. Most notably, the target of a valid
-symbolic link must be expressed as a UNIX-style path and it must exist
+symbolic link must be expressed as a Unix-style path and it must exist
on a volume visible from your POSIX root (see the C<SHOW ROOT> command
in DCL help). For further details on symbolic link capabilities and
requirements, see chapter 12 of the CRTL manual that ships with OpenVMS
$define DISPLAY "hostname:0.0"
Currently the value of C<DISPLAY> is ignored. It is recommended that it be set
-to be the hostname of the display, the server and screen in UNIX notation. In
+to be the hostname of the display, the server and screen in Unix notation. In
the future the value of DISPLAY may be honored by Perl instead of using the
default display.
When C<PERL_VMS_POSIX_EXIT> is active (see L</"$?"> below), the native VMS exit
status value will have either one of the C<$!> or C<$?> or C<$^E> or
-the UNIX value 255 encoded into it in a way that the effective original
+the Unix value 255 encoded into it in a way that the effective original
value can be decoded by other programs written in C, including Perl
and the GNV package. As per the normal non-VMS behavior of C<die> if
either C<$!> or C<$?> are non-zero, one of those values will be
-encoded into a native VMS status value. If both of the UNIX status
+encoded into a native VMS status value. If both of the Unix status
values are 0, and the C<$^E> value is set one of ERROR or SEVERE_ERROR
severity, then the C<$^E> value will be used as the exit code as is.
-If none of the above apply, the UNIX value of 255 will be encoded into
+If none of the above apply, the Unix value of 255 will be encoded into
a native VMS exit status value.
Please note a significant difference in the behavior of C<die> in
the C<PERL_VMS_POSIX_EXIT> mode is that it does not force a VMS
-SEVERE_ERROR status on exit. The UNIX exit values of 2 through
+SEVERE_ERROR status on exit. The Unix exit values of 2 through
255 will be encoded in VMS status values with severity levels of
-SUCCESS. The UNIX exit value of 1 will be encoded in a VMS status
+SUCCESS. The Unix exit value of 1 will be encoded in a VMS status
value with a severity level of ERROR. This is to be compatible with
how the VMS C library encodes these values.
may be changed to be ERROR or higher in the future depending on the
results of testing and further review.
-See L</"$?"> for a description of the encoding of the UNIX value to
+See L</"$?"> for a description of the encoding of the Unix value to
produce a native VMS status containing it.
contain the actual value of 0 to 255 returned by that program
on a normal exit.
-With the _POSIX_EXIT macro set, the UNIX exit value of zero is
-represented as a VMS native status of 1, and the UNIX values
+With the _POSIX_EXIT macro set, the Unix exit value of zero is
+represented as a VMS native status of 1, and the Unix values
from 2 to 255 are encoded by the equation:
VMS_status = 0x35a000 + (unix_value * 8) + 1.
-And in the special case of unix value 1 the encoding is:
+And in the special case of Unix value 1 the encoding is:
VMS_status = 0x35a000 + 8 + 2 + 0x10000000.
For other termination statuses, the severity portion of the
-subprocess' exit status is used: if the severity was success or
+subprocess's exit status is used: if the severity was success or
informational, these bits are all 0; if the severity was
warning, they contain a value of 1; if the severity was
error or fatal error, they contain the actual severity bits,
which turns out to be a value of 2 for error and 4 for severe_error.
Fatal is another term for the severe_error status.
-As a result, C<$?> will always be zero if the subprocess' exit
+As a result, C<$?> will always be zero if the subprocess's exit
status indicated successful completion, and non-zero if a
warning or error occurred or a program compliant with encoding
_POSIX_EXIT values was run and set a status.
How can you tell the difference between a non-zero status that is
-the result of a VMS native error status or an encoded UNIX status?
+the result of a VMS native error status or an encoded Unix status?
You can not unless you look at the ${^CHILD_ERROR_NATIVE} value.
The ${^CHILD_ERROR_NATIVE} value returns the actual VMS status value
and check the severity bits. If the severity bits are equal to 1,
then if the numeric value for C<$?> is between 2 and 255 or 0, then
-C<$?> accurately reflects a value passed back from a UNIX application.
+C<$?> accurately reflects a value passed back from a Unix application.
If C<$?> is 1, and the severity bits indicate a VMS error (2), then
-C<$?> is from a UNIX application exit value.
+C<$?> is from a Unix application exit value.
In practice, Perl scripts that call programs that return _POSIX_EXIT
type status values will be expecting those values, and programs that
And success is always the value 0 in all behaviors.
When the actual VMS termination status of the child is an error,
-internally the C<$!> value will be set to the closest UNIX errno
+internally the C<$!> value will be set to the closest Unix errno
value to that error so that Perl scripts that test for error
-messages will see the expected UNIX style error message instead
+messages will see the expected Unix style error message instead
of a VMS message.
Conversely, when setting C<$?> in an END block, an attempt is made
almost a NOOP as it will cause the current native VMS status in the
C library to become the current native Perl VMS status, and is handled
this way as it is known to not be a valid native VMS status value.
-It is recommend that only values in the range of normal UNIX parent or
+It is recommend that only values in the range of normal Unix parent or
child status numbers, 0 to 255 are used.
The pragma C<use vmsish 'status'> makes C<$?> reflect the actual
projects / p5sagit/p5-mst-13.2.git / commitdiff