At 12:06 2003-02-27 +0100, Toph Kemmann wrote:
FTR, this means that the remainder of the procmail recipes in this file are
executed at the user's UID. So noting permissions for the invoked program,
script, and output file (in addition to the test user) are all rather
| /usr/local/bin/php "/www/script_auto.php >> /var/log/script.log";
So, does the user have the right to write to /var/log/script.log ? Or
Since _procmail_ is invoking the php binary to run the script, procmail
won't be reporting permission errors with WHY the php binary can't run -
merely that it failed to execute (returned a nonzero or failed to read all
of its input).
procmail: Executing " /usr/local/bin/php "/www/script_auto.php >>
procmail: Error while writing to " /usr/local/bin/php "/www/script_auto.php
This is indicative of an invoked program which did not READ all of the
message content it was provided. Please review 'man procmailrc' for the
flags you should be using to _i_gnore write errors if your invoked script
isn't reading all of it's input.
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?
PHP wasn't originally a shell-invoked script language, such as Perl,
Python, etc. It is a webdev language, often used inline to HTML code, in
a module in the httpd before the document is sent to the user, so the
client s/w doesn't interpret it, it just ends up with the output of PHP:
<?PHP print( "whatever" ); ?>
You wouldn't _want_ a "#!/usr/local/bin/php" as the first line of an HTML
file because that would be sent to a client. On a php-only script file,
it'd be possible to make it executable and toss in such a line, but on a
script which might instead be html, it'd be undesireable. However, on a
PHP file intended for direct invocation (or being included), this shouldn't
be a problem. Note that the .php extension DOES NOT imply that it doesn't
contain bounding HTML tags - plenty of webservers use .php as a default webdoc.
Information on PHP-CLI, for those who need a refresher:
Sean B. Straw / Professional Software Engineering
Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
Please DO NOT carbon me on list replies. I'll get my copy from the list.
procmail mailing list