FAQ 2.0: How can I convince my sysadmin/supervisor/employees to use version 5/5.6.1/Perl i...

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

This message is one of several periodic postings to comp.lang.perl.misc
intended to make it easier for perl programmers to find answers to
common questions. The core of this message represents an excerpt
from the documentation provided with Perl.


2.0: How can I convince my sysadmin/supervisor/employees to use version
5/5.6.1/Perl instead of some other language?

    If your manager or employees are wary of unsupported software, or
    software which doesn't officially ship with your operating system, you
    might try to appeal to their self-interest. If programmers can be more
    productive using and utilizing Perl constructs, functionality,
    simplicity, and power, then the typical manager/supervisor/employee may
    be persuaded. Regarding using Perl in general, it's also sometimes
    helpful to point out that delivery times may be reduced using Perl
    compared to other languages.

    If you have a project which has a bottleneck, especially in terms of
    translation or testing, Perl almost certainly will provide a viable,
    quick solution. In conjunction with any persuasion effort, you should
    not fail to point out that Perl is used, quite extensively, and with
    extremely reliable and valuable results, at many large computer software
    and hardware companies throughout the world. In fact, many Unix vendors
    now ship Perl by default. Support is usually just a news-posting away,
    if you can't find the answer in the *comprehensive* documentation,
    including this FAQ.

    See http://www.perl.org/advocacy/ for more information.

    If you face reluctance to upgrading from an older version of perl, then
    point out that version 4 is utterly unmaintained and unsupported by the
    Perl Development Team. Another big sell for Perl5 is the large number of
    modules and extensions which greatly reduce development time for any
    given task. Also mention that the difference between version 4 and
    version 5 of Perl is like the difference between awk and C++. (Well, OK,
    maybe it's not quite that distinct, but you get the idea.) If you want
    support and a reasonable guarantee that what you're developing will
    continue to work in the future, then you have to run the supported
    version. As of December 2003 that means running either 5.8.2 (released
    in November 2003), or one of the older releases like 5.6.2 (also
    released in November 2003; a maintenance release to let perl 5.6 compile
    on newer systems as 5.6.1 was released in April 2001) or 5.005_03
    (released in March 1999), although 5.004_05 isn't that bad if you
    absolutely need such an old version (released in April 1999) for
    stability reasons. Anything older than 5.004_05 shouldn't be used.

    Of particular note is the massive bug hunt for buffer overflow problems
    that went into the 5.004 release. All releases prior to that, including
    perl4, are considered insecure and should be upgraded as soon as

    In August 2000 in all Linux distributions a new security problem was
    found in the optional 'suidperl' (not built or installed by default) in
    all the Perl branches 5.6, 5.005, and 5.004, see
    http://www.cpan.org/src/5.0/sperl-2000-08-05/ Perl maintenance releases
    5.6.1 and 5.8.0 have this security hole closed. Most, if not all, Linux
    distribution have patches for this vulnerability available, see
    http://www.linuxsecurity.com/advisories/ , but the most recommendable
    way is to upgrade to at least Perl 5.6.1.


Documents such as this have been called "Answers to Frequently
Asked Questions" or FAQ for short.  They represent an important
part of the Usenet tradition.  They serve to reduce the volume of
redundant traffic on a news group by providing quality answers to
questions that keep coming up.

If you are some how irritated by seeing these postings you are free
to ignore them or add the sender to your killfile.  If you find
errors or other problems with these postings please send corrections
or comments to the posting email address or to the maintainers as
directed in the perlfaq manual page.

Note that the FAQ text posted by this server may have been modified
from that distributed in the stable Perl release.  It may have been
edited to reflect the additions, changes and corrections provided
by respondents, reviewers, and critics to previous postings of
these FAQ. Complete text of these FAQ are available on request.

The perlfaq manual page contains the following copyright notice.


    Copyright (c) 1997-2002 Tom Christiansen and Nathan
    Torkington, and other contributors as noted. All rights

This posting is provided in the hope that it will be useful but
does not represent a commitment or contract of any kind on the part
of the contributers, authors or their agents.

Site Timeline