phpman > perldoc > id(2)

Found in /usr/share/perl/5.34/pod/perlfaq3.pod
  Is there an IDE or Windows Perl Editor?
    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
    philosophy is the philosophy of several small tools that each do one
    thing and do it well. It's like a carpenter's toolbox.

    If you want an IDE, check the following (in alphabetical order, not
    order of preference):

    Eclipse
        <http://e-p-i-c.sf.net/>

        The Eclipse Perl Integration Project integrates Perl
        editing/debugging with Eclipse.

    Enginsite
        <http://www.enginsite.com/>

        Perl Editor by EngInSite is a complete integrated development
        environment (IDE) for creating, testing, and debugging Perl scripts;
        the tool runs on Windows 9x/NT/2000/XP or later.

    IntelliJ IDEA
        <https://plugins.jetbrains.com/plugin/7796>

        Camelcade plugin provides Perl5 support in IntelliJ IDEA and other
        JetBrains IDEs.

    Kephra
        <http://kephra.sf.net>

        GUI editor written in Perl using wxWidgets and Scintilla with lots
        of smaller features. Aims for a UI based on Perl principles like
        TIMTOWTDI and "easy things should be easy, hard things should be
        possible".

    Komodo
        <http://www.ActiveState.com/Products/Komodo/>

        ActiveState's cross-platform (as of October 2004, that's Windows,
        Linux, and Solaris), multi-language IDE has Perl support, including
        a regular expression debugger and remote debugging.

    Notepad++
        <http://notepad-plus.sourceforge.net/>

    Open Perl IDE
        <http://open-perl-ide.sourceforge.net/>

        Open Perl IDE is an integrated development environment for writing
        and debugging Perl scripts with ActiveState's ActivePerl
        distribution under Windows 95/98/NT/2000.

    OptiPerl
        <http://www.optiperl.com/>

        OptiPerl is a Windows IDE with simulated CGI environment, including
        debugger and syntax-highlighting editor.

    Padre
        <http://padre.perlide.org/>

        Padre is cross-platform IDE for Perl written in Perl using wxWidgets
        to provide a native look and feel. It's open source under the
        Artistic License. It is one of the newer Perl IDEs.

    PerlBuilder
        <http://www.solutionsoft.com/perl.htm>

        PerlBuilder is an integrated development environment for Windows
        that supports Perl development.

    visiPerl+
        <http://helpconsulting.net/visiperl/index.html>

        From Help Consulting, for Windows.

    Visual Perl
        <http://www.activestate.com/Products/Visual_Perl/>

        Visual Perl is a Visual Studio.NET plug-in from ActiveState.

    Zeus
        <http://www.zeusedit.com/lookmain.html>

        Zeus for Windows is another Win32 multi-language editor/IDE that
        comes with support for Perl.

    For editors: if you're on Unix you probably have vi or a vi clone
    already, and possibly an emacs too, so you may not need to download
    anything. In any emacs the cperl-mode (M-x cperl-mode) gives you perhaps
    the best available Perl editing mode in any editor.

    If you are using Windows, you can use any editor that lets you work with
    plain text, such as NotePad or WordPad. Word processors, such as
    Microsoft Word or WordPerfect, typically do not work since they insert
    all sorts of behind-the-scenes information, although some allow you to
    save files as "Text Only". You can also download text editors designed
    specifically for programming, such as Textpad (
    <http://www.textpad.com/> ) and UltraEdit ( <http://www.ultraedit.com/>
    ), among others.

    If you are using MacOS, the same concerns apply. MacPerl (for Classic
    environments) comes with a simple editor. Popular external editors are
    BBEdit ( <http://www.barebones.com/products/bbedit/> ) or Alpha (
    <http://www.his.com/~jguyer/Alpha/Alpha8.html> ). MacOS X users can use
    Unix editors as well.

    GNU Emacs
        <http://www.gnu.org/software/emacs/windows/ntemacs.html>

    MicroEMACS
        <http://www.microemacs.de/>

    XEmacs
        <http://www.xemacs.org/Download/index.html>

    Jed <http://space.mit.edu/~davis/jed/>

    or a vi clone such as

    Vim <http://www.vim.org/>

    Vile
        <http://invisible-island.net/vile/vile.html>

    The following are Win32 multilanguage editor/IDEs that support Perl:

    MultiEdit
        <http://www.MultiEdit.com/>

    SlickEdit
        <http://www.slickedit.com/>

    ConTEXT
        <http://www.contexteditor.org/>

    There is also a toyedit Text widget based editor written in Perl that is
    distributed with the Tk module on CPAN. The ptkdb (
    <http://ptkdb.sourceforge.net/> ) is a Perl/Tk-based debugger that acts
    as a development environment of sorts. Perl Composer (
    <http://perlcomposer.sourceforge.net/> ) is an IDE for Perl/Tk GUI
    creation.

    In addition to an editor/IDE you might be interested in a more powerful
    shell environment for Win32. Your options include

    bash
        from the Cygwin package ( <http://cygwin.com/> )

    zsh <http://www.zsh.org/>

    Cygwin is covered by the GNU General Public License (but that shouldn't
    matter for Perl use). Cygwin contains (in addition to the shell) a
    comprehensive set of standard Unix toolkit utilities.

    BBEdit and TextWrangler
        are text editors for OS X that have a Perl sensitivity mode (
        <http://www.barebones.com/> ).

  How can I hide the source for my Perl program?
    Delete it. :-) Seriously, there are a number of (mostly unsatisfactory)
    solutions with varying levels of "security".

    First of all, however, you *can't* take away read permission, because
    the source code has to be readable in order to be compiled and
    interpreted. (That doesn't mean that a CGI script's source is readable
    by people on the web, though--only by people with access to the
    filesystem.) So you have to leave the permissions at the socially
    friendly 0755 level.

    Some people regard this as a security problem. If your program does
    insecure things and relies on people not knowing how to exploit those
    insecurities, it is not secure. It is often possible for someone to
    determine the insecure things and exploit them without viewing the
    source. Security through obscurity, the name for hiding your bugs
    instead of fixing them, is little security indeed.

    You can try using encryption via source filters (Starting from Perl 5.8
    the Filter::Simple and Filter::Util::Call modules are included in the
    standard distribution), but any decent programmer will be able to
    decrypt it. You can try using the byte code compiler and interpreter
    described later in perlfaq3, but the curious might still be able to
    de-compile it. You can try using the native-code compiler described
    later, but crackers might be able to disassemble it. These pose varying
    degrees of difficulty to people wanting to get at your code, but none
    can definitively conceal it (true of every language, not just Perl).

    It is very easy to recover the source of Perl programs. You simply feed
    the program to the perl interpreter and use the modules in the B::
    hierarchy. The B::Deparse module should be able to defeat most attempts
    to hide source. Again, this is not unique to Perl.

    If you're concerned about people profiting from your code, then the
    bottom line is that nothing but a restrictive license will give you
    legal security. License your software and pepper it with threatening
    statements like "This is unpublished proprietary software of XYZ Corp.
    Your access to it does not give you permission to use it blah blah
    blah." We are not lawyers, of course, so you should see a lawyer if you
    want to be sure your license's wording will stand up in court.

Found in /usr/share/perl/5.34/pod/perlfaq4.pod
  How do I validate input?
    (contributed by brian d foy)

    There are many ways to ensure that values are what you expect or want to
    accept. Besides the specific examples that we cover in the perlfaq, you
    can also look at the modules with "Assert" and "Validate" in their
    names, along with other modules such as Regexp::Common.

    Some modules have validation for particular types of input, such as
    Business::ISBN, Business::CreditCard, Email::Valid, and
    Data::Validate::IP.

  How can I split a [character]-delimited string except when inside [character]?
    Several modules can handle this sort of parsing--Text::Balanced,
    Text::CSV, Text::CSV_XS, and Text::ParseWords, among others.

    Take the example case of trying to split a string that is
    comma-separated into its different fields. You can't use "split(/,/)"
    because you shouldn't split if the comma is inside quotes. For example,
    take a data line like this:

        SAR001,"","Cimetrix, Inc","Bob Smith","CAM",N,8,1,0,7,"Error, Core Dumped"

    Due to the restriction of the quotes, this is a fairly complex problem.
    Thankfully, we have Jeffrey Friedl, author of *Mastering Regular
    Expressions*, to handle these for us. He suggests (assuming your string
    is contained in $text):

         my @new = ();
         push(@new, $+) while $text =~ m{
             "([^\"\\]*(?:\\.[^\"\\]*)*)",? # groups the phrase inside the quotes
            | ([^,]+),?
            | ,
         }gx;
         push(@new, undef) if substr($text,-1,1) eq ',';

    If you want to represent quotation marks inside a
    quotation-mark-delimited field, escape them with backslashes (eg, "like
    \"this\"".

    Alternatively, the Text::ParseWords module (part of the standard Perl
    distribution) lets you say:

        use Text::ParseWords;
        @new = quotewords(",", 0, $text);

    For parsing or generating CSV, though, using Text::CSV rather than
    implementing it yourself is highly recommended; you'll save yourself odd
    bugs popping up later by just using code which has already been tried
    and tested in production for years.

  How can I store a multidimensional array in a DBM file?
    Either stringify the structure yourself (no fun), or else get the MLDBM
    (which uses Data::Dumper) module from CPAN and layer it on top of either
    DB_File or GDBM_File. You might also try DBM::Deep, but it can be a bit
    slow.

Found in /usr/share/perl/5.34/pod/perlfaq6.pod
  I put a regular expression into $/ but it didn't work. What's wrong?
    $/ has to be a string. You can use these examples if you really need to
    do this.

    If you have File::Stream, this is easy.

        use File::Stream;

        my $stream = File::Stream->new(
            $filehandle,
            separator => qr/\s*,\s*/,
            );

        print "$_\n" while <$stream>;

    If you don't have File::Stream, you have to do a little more work.

    You can use the four-argument form of sysread to continually add to a
    buffer. After you add to the buffer, you check if you have a complete
    line (using your regular expression).

        local $_ = "";
        while( sysread FH, $_, 8192, length ) {
            while( s/^((?s).*?)your_pattern// ) {
                my $record = $1;
                # do stuff here.
            }
        }

    You can do the same thing with foreach and a match using the c flag and
    the \G anchor, if you do not mind your entire file being in memory at
    the end.

        local $_ = "";
        while( sysread FH, $_, 8192, length ) {
            foreach my $record ( m/\G((?s).*?)your_pattern/gc ) {
                # do stuff here.
            }
            substr( $_, 0, pos ) = "" if pos;
        }

  What's wrong with using grep in a void context?
    The problem is that grep builds a return list, regardless of the
    context. This means you're making Perl go to the trouble of building a
    list that you then just throw away. If the list is large, you waste both
    time and space. If your intent is to iterate over the list, then use a
    for loop for this purpose.

    In perls older than 5.8.1, map suffers from this problem as well. But
    since 5.8.1, this has been fixed, and map is context aware - in void
    context, no lists are constructed.

Found in /usr/share/perl/5.34/pod/perlfaq7.pod
  What is variable suicide and how can I prevent it?
    This problem was fixed in perl 5.004_05, so preventing it means
    upgrading your version of perl. ;)

    Variable suicide is when you (temporarily or permanently) lose the value
    of a variable. It is caused by scoping through my() and local()
    interacting with either closures or aliased foreach() iterator variables
    and subroutine arguments. It used to be easy to inadvertently lose a
    variable's value this way, but now it's much harder. Take this code:

        my $f = 'foo';
        sub T {
            while ($i++ < 3) { my $f = $f; $f .= "bar"; print $f, "\n" }
        }

        T;
        print "Finally $f\n";

    If you are experiencing variable suicide, that "my $f" in the subroutine
    doesn't pick up a fresh copy of the $f whose value is 'foo'. The output
    shows that inside the subroutine the value of $f leaks through when it
    shouldn't, as in this output:

        foobar
        foobarbar
        foobarbarbar
        Finally foo

    The $f that has "bar" added to it three times should be a new $f "my $f"
    should create a new lexical variable each time through the loop. The
    expected output is:

        foobar
        foobar
        foobar
        Finally foo

Found in /usr/share/perl/5.34/pod/perlfaq8.pod
  Why do setuid perl scripts complain about kernel problems?
    Some operating systems have bugs in the kernel that make setuid scripts
    inherently insecure. Perl gives you a number of options (described in
    perlsec) to work around such systems.

  What's wrong with using backticks in a void context?
    Strictly speaking, nothing. Stylistically speaking, it's not a good way
    to write maintainable code. Perl has several operators for running
    external commands. Backticks are one; they collect the output from the
    command for use in your program. The "system" function is another; it
    doesn't do this.

    Writing backticks in your program sends a clear message to the readers
    of your code that you wanted to collect the output of the command. Why
    send a clear message that isn't true?

    Consider this line:

        `cat /etc/termcap`;

    You forgot to check $? to see whether the program even ran correctly.
    Even if you wrote

        print `cat /etc/termcap`;

    this code could and probably should be written as

        system("cat /etc/termcap") == 0
        or die "cat program failed!";

    which will echo the cat command's output as it is generated, instead of
    waiting until the program has completed to print it out. It also checks
    the return value.

    "system" also provides direct control over whether shell wildcard
    processing may take place, whereas backticks do not.

  Is there a way to hide perl's command line from programs such as "ps"?
    First of all note that if you're doing this for security reasons (to
    avoid people seeing passwords, for example) then you should rewrite your
    program so that critical information is never given as an argument.
    Hiding the arguments won't make your program completely secure.

    To actually alter the visible command line, you can assign to the
    variable $0 as documented in perlvar. This won't work on all operating
    systems, though. Daemon programs like sendmail place their state there,
    as in:

        $0 = "orcus [accepting connections]";

  How do I avoid zombies on a Unix system?
    Use the reaper code from "Signals" in perlipc to call "wait()" when a
    SIGCHLD is received, or else use the double-fork technique described in
    "How do I start a process in the background?" in perlfaq8.

Found in /usr/share/perl/5.34/pod/perlfaq9.pod
  How do I check a valid mail address?
    (partly contributed by Aaron Sherman)

    This isn't as simple a question as it sounds. There are two parts:

    a) How do I verify that an email address is correctly formatted?

    b) How do I verify that an email address targets a valid recipient?

    Without sending mail to the address and seeing whether there's a human
    on the other end to answer you, you cannot fully answer part *b*, but
    the Email::Valid module will do both part *a* and part *b* as far as you
    can in real-time.

    Our best advice for verifying a person's mail address is to have them
    enter their address twice, just as you normally do to change a password.
    This usually weeds out typos. If both versions match, send mail to that
    address with a personal message. If you get the message back and they've
    followed your directions, you can be reasonably assured that it's real.

    A related strategy that's less open to forgery is to give them a PIN
    (personal ID number). Record the address and PIN (best that it be a
    random one) for later processing. In the mail you send, include a link
    to your site with the PIN included. If the mail bounces, you know it's
    not valid. If they don't click on the link, either they forged the
    address or (assuming they got the message) following through wasn't
    important so you don't need to worry about it.