phpman > perldoc > foo(42)

Found in /usr/share/perl/5.34/pod/perlfaq5.pod
  How can I set up a footer format to be used with write()?
    There's no builtin way to do this, but perlform has a couple of
    techniques to make it possible for the intrepid hacker.

  Why can't I use "C:\temp\foo" in DOS paths? Why doesn't `C:\temp\foo.exe` work?
    Whoops! You just put a tab and a formfeed into that filename! Remember
    that within double quoted strings ("like\this"), the backslash is an
    escape character. The full list of these is in "Quote and Quote-like
    Operators" in perlop. Unsurprisingly, you don't have a file called
    "c:(tab)emp(formfeed)oo" or "c:(tab)emp(formfeed)oo.exe" on your legacy
    DOS filesystem.

    Either single-quote your strings, or (preferably) use forward slashes.
    Since all DOS and Windows versions since something like MS-DOS 2.0 or so
    have treated "/" and "\" the same in a path, you might as well use the
    one that doesn't clash with Perl--or the POSIX shell, ANSI C and C++,
    awk, Tcl, Java, or Python, just to mention a few. POSIX paths are more
    portable, too.

Found in /usr/share/perl/5.34/pod/perlfaq7.pod
  Why doesn't "my($foo) = <$fh>;" work right?
    "my()" and "local()" give list context to the right hand side of "=".
    The <$fh> read operation, like so many of Perl's functions and
    operators, can tell which context it was called in and behaves
    appropriately. In general, the scalar() function can help. This function
    does nothing to the data itself (contrary to popular myth) but rather
    tells its argument to behave in whatever its scalar fashion is. If that
    function doesn't have a defined scalar behavior, this of course doesn't
    help you (such as with sort()).

    To enforce scalar context in this particular case, however, you need
    merely omit the parentheses:

        local($foo) = <$fh>;        # WRONG
        local($foo) = scalar(<$fh>);   # ok
        local $foo  = <$fh>;        # right

    You should probably be using lexical variables anyway, although the
    issue is the same here:

        my($foo) = <$fh>;    # WRONG
        my $foo  = <$fh>;    # right

  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.