Call(3pm) - man - phpMan

Found in /usr/share/perl/5.34/pod/perlfaq4.pod
  How do I expand function calls in a string?
    (contributed by brian d foy)

    This is documented in perlref, and although it's not the easiest thing
    to read, it does work. In each of these examples, we call the function
    inside the braces used to dereference a reference. If we have more than
    one return value, we can construct and dereference an anonymous array.
    In this case, we call the function in list context.

        print "The time values are @{ [localtime] }.\n";

    If we want to call the function in scalar context, we have to do a bit
    more work. We can really have any code we like inside the braces, so we
    simply have to end with the scalar reference, although how you do that
    is up to you, and you can use code inside the braces. Note that the use
    of parens creates a list context, so we need "scalar" to force the
    scalar context on the function:

        print "The time is ${\(scalar localtime)}.\n"

        print "The time is ${ my $x = localtime; \$x }.\n";

    If your function already returns a reference, you don't need to create
    the reference yourself.

        sub timestamp { my $t = localtime; \$t }

        print "The time is ${ timestamp() }.\n";

    The "Interpolation" module can also do a lot of magic for you. You can
    specify a variable name, in this case "E", to set up a tied hash that
    does the interpolation for you. It has several other methods to do this
    as well.

        use Interpolation E => 'eval';
        print "The time values are $E{localtime()}.\n";

    In most cases, it is probably easier to simply use string concatenation,
    which also forces scalar context.

        print "The time is " . localtime() . ".\n";

  How do I keep persistent data across program calls?
    For some specific applications, you can use one of the DBM modules. See
    AnyDBM_File. More generically, you should consult the FreezeThaw or
    Storable modules from CPAN. Starting from Perl 5.8, Storable is part of
    the standard distribution. Here's one example using Storable's "store"
    and "retrieve" functions:

        use Storable;
        store(\%hash, "filename");

        # later on...
        $href = retrieve("filename");        # by ref
        %hash = %{ retrieve("filename") };   # direct to hash

Found in /usr/share/perl/5.34/pod/perlfaq7.pod
  What's the difference between calling a function as &foo and foo()?
    (contributed by brian d foy)

    Calling a subroutine as &foo with no trailing parentheses ignores the
    prototype of "foo" and passes it the current value of the argument list,
    @_. Here's an example; the "bar" subroutine calls &foo, which prints its
    arguments list:

        sub foo { print "Args in foo are: @_\n"; }

        sub bar { &foo; }

        bar( "a", "b", "c" );

    When you call "bar" with arguments, you see that "foo" got the same @_:

        Args in foo are: a b c

    Calling the subroutine with trailing parentheses, with or without
    arguments, does not use the current @_. Changing the example to put
    parentheses after the call to "foo" changes the program:

        sub foo { print "Args in foo are: @_\n"; }

        sub bar { &foo(); }

        bar( "a", "b", "c" );

    Now the output shows that "foo" doesn't get the @_ from its caller.

        Args in foo are:

    However, using "&" in the call still overrides the prototype of "foo" if
    present:

        sub foo ($$$) { print "Args infoo are: @_\n"; }

        sub bar_1 { &foo; }
        sub bar_2 { &foo(); }
        sub bar_3 { foo( $_[0], $_[1], $_[2] ); }
        # sub bar_4 { foo(); }
        # bar_4 doesn't compile: "Not enough arguments for main::foo at ..."

        bar_1( "a", "b", "c" );
        # Args in foo are: a b c

        bar_2( "a", "b", "c" );
        # Args in foo are:

        bar_3( "a", "b", "c" );
        # Args in foo are: a b c

    The main use of the @_ pass-through feature is to write subroutines
    whose main job it is to call other subroutines for you. For further
    details, see perlsub.

  How can I find out my current or calling package?
    (contributed by brian d foy)

    To find the package you are currently in, use the special literal
    "__PACKAGE__", as documented in perldata. You can only use the special
    literals as separate tokens, so you can't interpolate them into strings
    like you can with variables:

        my $current_package = __PACKAGE__;
        print "I am in package $current_package\n";

    If you want to find the package calling your code, perhaps to give
    better diagnostics as Carp does, use the "caller" built-in:

        sub foo {
            my @args = ...;
            my( $package, $filename, $line ) = caller;

            print "I was called from package $package\n";
            );

    By default, your program starts in package "main", so you will always be
    in some package.

    This is different from finding out the package an object is blessed
    into, which might not be the current package. For that, use "blessed"
    from Scalar::Util, part of the Standard Library since Perl 5.8:

        use Scalar::Util qw(blessed);
        my $object_package = blessed( $object );

    Most of the time, you shouldn't care what package an object is blessed
    into, however, as long as it claims to inherit from that class:

        my $is_right_class = eval { $object->isa( $package ) }; # true or false

    And, with Perl 5.10 and later, you don't have to check for an
    inheritance to see if the object can handle a role. For that, you can
    use "DOES", which comes from "UNIVERSAL":

        my $class_does_it = eval { $object->DOES( $role ) }; # true or false

    You can safely replace "isa" with "DOES" (although the converse is not
    true).

Found in /usr/share/perl/5.34/pod/perlfaq8.pod
  How can I call my system's unique C functions from Perl?
    In most cases, you write an external module to do it--see the answer to
    "Where can I learn about linking C with Perl? [h2xs, xsubpp]". However,
    if the function is a system call, and your system supports "syscall()",
    you can use the "syscall" function (documented in perlfunc).

    Remember to check the modules that came with your distribution, and CPAN
    as well--someone may already have written a module to do it. On Windows,
    try Win32::API. On Macs, try Mac::Carbon. If no module has an interface
    to the C function, you can inline a bit of C in your Perl source with
    Inline::C.

  Where do I get the include files to do ioctl() or syscall()?
    Historically, these would be generated by the h2ph tool, part of the
    standard perl distribution. This program converts cpp(1) directives in C
    header files to files containing subroutine definitions, like
    "SYS_getitimer()", which you can use as arguments to your functions. It
    doesn't work perfectly, but it usually gets most of the job done. Simple
    files like errno.h, syscall.h, and socket.h were fine, but the hard ones
    like ioctl.h nearly always need to be hand-edited. Here's how to install
    the *.ph files:

        1. Become the super-user
        2. cd /usr/include
        3. h2ph *.h */*.h

    If your system supports dynamic loading, for reasons of portability and
    sanity you probably ought to use h2xs (also part of the standard perl
    distribution). This tool converts C header files to Perl extensions. See
    perlxstut for how to get started with h2xs.

    If your system doesn't support dynamic loading, you still probably ought
    to use h2xs. See perlxstut and ExtUtils::MakeMaker for more information
    (in brief, just use make perl instead of a plain make to rebuild perl
    with a new static extension).

  How can I call backticks without shell processing?
    This is a bit tricky. You can't simply write the command like this:

        @ok = `grep @opts '$search_string' @filenames`;

    As of Perl 5.8.0, you can use "open()" with multiple arguments. Just
    like the list forms of "system()" and "exec()", no shell escapes happen.

        open( GREP, "-|", 'grep', @opts, $search_string, @filenames );
        chomp(@ok = <GREP>);
        close GREP;

    You can also:

        my @ok = ();
        if (open(GREP, "-|")) {
            while (<GREP>) {
                chomp;
                push(@ok, $_);
            }
            close GREP;
        } else {
            exec 'grep', @opts, $search_string, @filenames;
        }

    Just as with "system()", no shell escapes happen when you "exec()" a
    list. Further examples of this can be found in "Safe Pipe Opens" in
    perlipc.

    Note that if you're using Windows, no solution to this vexing issue is
    even possible. Even though Perl emulates "fork()", you'll still be
    stuck, because Windows does not have an argc/argv-style API.