procmail
[Top] [All Lists]

Re: Still having perl problems!

1996-12-05 11:44:53
    > I'm still having problems getting procmail to pipe my mail to a
    > perl script.  It seems as if it insists on running the script
    > under the bourne shell (sh) which does not understand the
    > #!/usr/bin/perl at the beginning of the script.  I have included
    > below hopefully EVERYTHING that would be of use in determining
    > what the hell is going wrong and how to get things working...
    > 
    > BTW, the script does work as expected if I run it from the command
    > line (under tcsh).  Example: cat testfile | filter.pl
    > 
    > PERMISSIONS:
    > ============
    > 
    > Perl Binary:
    > lrwxrwxrwx   1 root     other          5 May 13  1996 /usr/bin/perl -> 
perl5*
    > lrwxrwxrwx   1 root     other          9 May 13  1996 /usr/bin/perl5 -> 
perl5.002*
    > -rwxr-xr-x   1 root     200       542248 May  2  1996 /usr/bin/perl5.002*
    > 
    > Path to (and including) perl script:
    > drwxr-xr-x 731 root     other      28672 Nov  6 13:09 homee/
    > drwxr-xr-x  13 downin   ipusers     4096 Dec  5 12:06 downin/
    > drwxr-xr-x   2 downin   ipusers     4096 Dec  4 10:23 nags/
    > -rwxr-xr-x   1 downin   ipusers    25172 Dec  3 16:37 filter.pl*
    > 
    > Procmail stuff:
    > -rwsr-sr-x   1 root     mail       65060 Nov  7  1994 
/usr/local/bin/procmail*
    > -rw-r--r--   1 downin   ipusers      391 Dec  4 10:27 .procmailrc
    > 
    > PROCMAILRC:
    > ===========
    > 
    > VERBOSE=yes
    > 
PATH=$HOME/bin:/usr/bin:/usr/ucb:/bin:/opt/local/bin:/usr/local/bin:/homee/downin/nags:.
    > MAILDIR=$HOME/Mail
    > DEFAULT=/var/mail/downin
    > LOGFILE=$MAILDIR/log
    > 
    > :0: nags_filter.lock
    > * ^From:(_dot_)*downin(_at_)reboot(_dot_)dt(_dot_)navy(_dot_)mil
    > |/homee/downin/nags/filter.pl
    > 
    > FILTER.PL (just the first few lines):
    > =====================================
    > #!/usr/bin/perl
    > $version="2.5";
    > $your_name="Dave Downin";
    > $your_email='downin(_at_)clark(_dot_)net';
    > $home_dir='/homee/downin';
    > $mailbox='/var/mail/downin';
    > @smtp_hosts=("mail.clark.net");
    > 
    > PROCMAIL LOG:
    > =============
    > procmail: Match on 
"^From:(_dot_)*downin(_at_)reboot(_dot_)dt(_dot_)navy(_dot_)mil"
    > procmail: Locking "nags_filter.lock"
    > procmail: Executing "/homee/downin/nags/filter.pl"
    > /homee/downin/nags/filter.pl: =2.5: not found
    > /homee/downin/nags/filter.pl: =Dave Downin: not found
    > /homee/downin/nags/filter.pl: =downin(_at_)clark(_dot_)net: not found
    > /homee/downin/nags/filter.pl: =/homee/downin: not found
    > /homee/downin/nags/filter.pl: =/var/mail/downin: not found
    > /homee/downin/nags/filter.pl: syntax error at line 86: 
`(_at_)smtp_hosts=' unexpected
    > procmail: Program failure (2) of "/homee/downin/nags/filter.pl"
    ... remaining errors omitted...

These error messages lead me to think, as you have also guessed, that
perhaps procmail is invoking "filter.pl" as a shell script, ie: "sh -c".

Perhaps, you just might try placing these lines at the top of your
"filter.pl", in case procmail is invoking the filter somehow, perhaps by
using "sh -c":

        #!/bin/sh -- # -*- perl -*- -p
        eval 'exec perl $0 -S ${1+"$@"}'
           if 0;

For more information on this technique, please see the "perlrun"
manpage.  The part in particular which says:


          As of Perl 5, the #! line is always examined for switches as
          the line is being parsed.  Thus, if you're on a machine that
          only allows one argument with the #! line, or worse, doesn't
          even recognize the #! line, you still can get consistent
          switch behavior regardless of how Perl was invoked, even if
          -x was used to find the beginning of the script.

          Because many operating systems silently chop off kernel
          interpretation of the #! line after 32 characters, some
          switches may be passed in on the command line, and some may
          not; you could even get a "-" without its letter, if you're
          not careful.  You probably want to make sure that all your
          switches fall either before or after that 32 character
          boundary.  Most switches don't actually care if they're
          processed redundantly, but getting a - instead of a complete
          switch could cause Perl to try to execute standard input
          instead of your script.  And a partial -I switch could also
          cause odd results.

          Parsing of the #! switches starts wherever "perl" is
          mentioned in the line.  The sequences "-*" and "- " are
          specifically ignored so that you could, if you were so
          inclined, say

              #!/bin/sh -- # -*- perl -*- -p
              eval 'exec perl $0 -S ${1+"$@"}'
                  if 0;

          to let Perl see the -p switch.

          If the #! line does not contain the word "perl", the program
          named after the #! is executed instead of the Perl
          interpreter.  This is slightly bizarre, but it helps people
          on machines that don't do #!, because they can tell a
          program that their SHELL is /usr/bin/perl, and Perl will
          then dispatch the program to the correct interpreter for
          them.

G'luck.
___________________________________________________________
Alan Stebbens <aks(_at_)sgi(_dot_)com>      http://reality.sgi.com/aks

<Prev in Thread] Current Thread [Next in Thread>