Mac Forum / Programming / Perl / July 2004

That is both against the documentation (env(1)) and the UNIX spec,
so I think a bug report to Apple is in order.  (Actually, env as such
seems to be working okay, so it is more likely a bug in the #! processing.)

Looking in the Camel, I'm not sure what the -l flag is supposed to
be doing for you.  You're not using it with -n or -p, so it isn't
auto-chomping the input lines; you didn't give it an argument, so
it isn't changing the output line terminator.  So, what's it for?

My Perl scripts, FWIW, all have the same general format:

#!/usr/bin/env perl
#
# foo - do fooish things
#
# ...

use Bar::Baz;            # bring in external modules
...

use strict;
use warnings;

{                # "main" routine
    our ($aa, ...        # globals used by main
        ...
        );

    my ($a, ...            # private variables
        ...
       );

    ...                # executable code
}

# foosub - do foosubbish things
#
sub foosub {

    my ($p1, ...) = @_;        # copies of input arguments

    our ($aa, ...        # globals used by foosub
         ...
        );

    my ($b, ...            # private variables
        ...
       );

    ...                # executable code
}

...                # more subs

The "use warnings" line takes the place of the "-w" flag.  The "use
strict" keeps me even more honest (:-).  Putting these lines AFTER
the "use Bar::Baz;" lines(s) prevents me from getting nastygrams
about coding practices in the imported module(s).

By putting the "main" code in a pair of brackets, I cause it to be
indented at the same starting level as the code in the subs.  This
also restricts the scope of its statements (e.g., "our"), so they
aren't global to the file.

To be totally honest, I often start out by using a single "our"
statement above the "main" block.  Then, when the code is stable,
I go back and replace this with specific "our" statements in the
"main" and sub blocks.  This gives me some freedom during the
early stages of development, but controls (and documents) the
visibility of the globals, while the code is in production use.

In any case, I try to keep the use of global variables down, as
overuse of globals can cause confusion...

-r