Hello and thanks Sean,
my script is been executed but I have another problem,
#LOCKFILE=/var/lock/.lockmail
DROPPRIVS=no
VERBOSE=yes
:0 i:
* ^To(_dot_)*bild(_at_)kemweb(_dot_)info
| /usr/local/bin/php /home/www/web1/html/getemail_auto.php >> /var/log/post.log
This php-script works with this special e-mail, it writes the attached
file into a database. But it does not, it says "nothing in e-mail". I
think the problem is, that procmail and the script are using the
e-mail at the same time and/or procmail write a temp-e-mail-file as
long as it works with it.
How can I change this ???
btw. where can I find a discription of the flags ":0:HWf..." and so
on, didŽnt find anything on man procmail ?
Thank
Toph
This
Thursday, February 27, 2003, 6:15:30 PM, you wrote:
PSE> At 12:06 2003-02-27 +0100, Toph Kemmann wrote:
/etc/procmailrc :
DROPPRIVS=yes
PSE> FTR, this means that the remainder of the procmail recipes in this file
are
PSE> executed at the user's UID. So noting permissions for the invoked
program,
PSE> script, and output file (in addition to the test user) are all rather
PSE> important considerations.
:0
* ^To(_dot_)*email(_at_)irgendwas(_dot_)info
| /usr/local/bin/php "/www/script_auto.php >> /var/log/script.log";
PSE> So, does the user have the right to write to /var/log/script.log ? Or
PSE> _read /www/script_auto.php?
PSE> Since _procmail_ is invoking the php binary to run the script, procmail
PSE> won't be reporting permission errors with WHY the php binary can't run -
PSE> merely that it failed to execute (returned a nonzero or failed to read all
PSE> of its input).
procmail: Executing " /usr/local/bin/php "/www/script_auto.php >>
/var/log/script.log";"
procmail: Error while writing to " /usr/local/bin/php "/www/script_auto.php
PSE> ^^^^^^^^^^^^^^^^^^^^^^
PSE> This is indicative of an invoked program which did not READ all of the
PSE> message content it was provided. Please review 'man procmailrc' for the
PSE> flags you should be using to _i_gnore write errors if your invoked script
PSE> isn't reading all of it's input.
PSE> Then, at 05:45 2003-02-27 -0700, LuKreme wrote:
Also, if the script_auto.php is executable (and written correctly), there
should be no need to invoke php?
PSE> PHP wasn't originally a shell-invoked script language, such as Perl,
PSE> Python, etc. It is a webdev language, often used inline to HTML code, in
PSE> much the same way as JavaScript would be inlined, but it is interpreted by
PSE> a module in the httpd before the document is sent to the user, so the
PSE> client s/w doesn't interpret it, it just ends up with the output of PHP:
PSE> <?PHP print( "whatever" ); ?>
PSE> You wouldn't _want_ a "#!/usr/local/bin/php" as the first line of an HTML
PSE> file because that would be sent to a client. On a php-only script file,
PSE> it'd be possible to make it executable and toss in such a line, but on a
PSE> script which might instead be html, it'd be undesireable. However, on a
PSE> PHP file intended for direct invocation (or being included), this
shouldn't
PSE> be a problem. Note that the .php extension DOES NOT imply that it doesn't
PSE> contain bounding HTML tags - plenty of webservers use .php as a default
webdoc.
PSE> Information on PHP-CLI, for those who need a refresher:
PSE> <http://www.php.net/manual/en/features.commandline.php>
--
Best regards,
Toph mailto:ck(_at_)keming(_dot_)de
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail