perldoc > foo(0)

man perldoc info pydoc3 ri search

🚀 Quick Reference

Use Case	Command	Description
Set footer format for write()	perlform techniques	No built‑in footer; craft one using perlform 🔧
Use DOS paths without escaping	use single quotes or forward slashes	Backslash is an escape inside double quotes ⚠️
Enforce scalar context with filehandle read	my $foo = <$fh>;	Omit parentheses to avoid list context 📝
Call a subroutine with &foo vs foo()	&foo; passes @_; &foo(); does not	Use & to override prototypes and pass @_ 🎯

📚 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.

📚 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.

🚀 Quick Reference 📚 perlfaq5.pod 📚 perlfaq7.pod