php-general Digest 25 Nov 2005 08:25:45 -0000 Issue 3814
Topics (messages 226417 through 226420):
Re: Can't execute external program
226417 by: Sandy Keathley
226420 by: n.g.
Re: Regexp trouble
226418 by: Frank Armitage
session cookies, domain (host:port) issues
226419 by: anirudh dutt
Administrivia:
To subscribe to the digest, e-mail:
[EMAIL PROTECTED]
To unsubscribe from the digest, e-mail:
[EMAIL PROTECTED]
To post to the list, e-mail:
php-general@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
> > Here is the php I've created, fairly simple:
> > <?php
> > exec("/var/www/html/myprog -E 123456789098.dat sample1.txt
> > sample1.new");
> > phpinfo();
> > ?>
> > From the command line it runs perfectly
A PHP script runs with the permissions of the user that Apache
runs as, usually "nobody". When run from the command line, it
inherits a different set of permissions (i.e., root).
One option would be to put a copy of the executable in another
directory, but OUTSIDE of your DOCROOT, and give it the same
ownership and perms as "nobody" (or whatever Apache runs as).
Of course, this makes your script 100% non-portable, if that
matters. It is also possible that the executable may not run, if it
depends on compiled libraries elsewhere on the server.
************************************************************
WebDesigns Internet Consulting
E-commerce Solutions
Application Development
Sandy Keathley
Zend Certified Engineer
[EMAIL PROTECTED]
972-569-8464
http://www.KeathleyWebs.com/
************************************************************
--- End Message ---
--- Begin Message ---
sorry , i have made mistake.
`option +exec' is not required, and there is no such apache option.
maybe you're running php in safe_mode ?
On 11/24/05, n.g. <[EMAIL PROTECTED]> wrote:
> put the executable into another directory rather than DOC_ROOT,
> maybe you have reached apache security settings.
> or try add `option +exec' to your apache conf, but be aware this maybe
> a security problem to your site to do so.
>
> On 11/24/05, Henry Castillo <[EMAIL PROTECTED]> wrote:
> > Hi
> > Still desperate
> > DOCUMENT_ROOT is /var/www/html
> > Check all settings at http://provi.voicenetworx.net:8080/t.php
> > From the command line it runs perfectly:
> > [EMAIL PROTECTED] html]# /var/www/html/myprog -E 123456789098.dat
> > sample1.txt
> > sample1.new
> > (no output, it just creates the file .new)
> >
> > Here is the php I've created, fairly simple:
> > <?php
> > exec("/var/www/html/myprog -E 123456789098.dat sample1.txt
> > sample1.new");
> > phpinfo();
> > ?>
> >
> >
> >
> > On 11/22/05, n.g. <[EMAIL PROTECTED]> wrote:
> > >
> > > is /var/www/html your web root dir ?
> > > maybe its the plobrem.
> > >
> > > On 11/23/05, Henry Castillo <[EMAIL PROTECTED]> wrote:
> > > > That was on of the first things I checked:
> > > > safe mode is set to off
> > > > Any ideas...
> > > > Henry
> > > > Voip tech said the following on 11/20/2005 10:31 PM:
> > > > > Hello,
> > > > > I cannot get exec(), system() or passthru() to run an extenal
> > program.
> > > > > From the command line it runs perfectly:
> > > >
> > > > <snip>
> > > >
> > > > > I'm getting frustrated, Any help will be deeply appreciated
> > > > > Henry
> > > >
> > > > The answer is probably in your php.ini. Look into whether you are
> > > > running in safe mode or not, and if you are whether you have your
> > > > program in the safe_mode_exec_dir or not. Also check
> disable_functions
> > > > to see if any of the ones you are having trouble with are listed.
> > > >
> > > > - Ben
> > > >
> > > >
> > >
> > >
> > > --
> > > Tomorrow will be a good day :-)
> > >
> >
> >
>
>
> --
> Tomorrow will be a good day :-)
>
--
Tomorrow will be a good day :-)
--- End Message ---
--- Begin Message ---
Andy Pieters wrote:
>
> Err.. why NOT use character classes? What is easier [0-9] or \d or maybe
> [a-zA-Z] or [\w], ... ?
>
Well, first of all the square brackets in [\w] aren't needed, \w already
means 'any "word" character'.
Secondly, [a-zA-Z] is not the same as \w:
" A "word" character is any letter or digit or the underscore character,
that is, any character which can be part of a Perl "word". The
definition of letters and digits is controlled by PCRE's character
tables, and may vary if locale-specific matching is taking place (see
"Locale support" above). For example, in the "fr" (French) locale, some
character codes greater than 128 are used for accented letters, and
these are matched by \w. "
[http://www.php.net/manual/en/reference.pcre.pattern.syntax.php]
Anyway I'm not really a great RegExp expert, a good starting point for
understanding regexp and PHP is, as usual, the manual:
http://www.php.net/manual/en/reference.pcre.pattern.syntax.php
Bye!
--
tradeOver | http://www.tradeover.net
...ready to become the King of the World?
--- End Message ---
--- Begin Message ---
hi
some thoughts on session cookies...
when setting the domain for the cookie, u could use
$_SERVER['HTTP_HOST'] which would be 'example.com' or
'www.example.com' i.e.
session_set_cookie_params(30*60, '/', $_SERVER['HTTP_HOST'], false);
(assuming u don't want to set it for subdomains)
if the webserver isn't running on port 80 then $_SERVER['HTTP_HOST']
is 'example.com:101'. on www.example.com:101 or sub.example.com:101,
$_SERVER['SERVER_NAME'] is 'example.com' in which case the browser
rejects it (which it's supposed to). ofcourse this could be solved by
doing something like
list ($host, $port) = split(':', $_SERVER['HTTP_HOST']);
$host is 'sub.example.com'
$port is '101'
if the 'domain' parameter in session_set_cookie_params is empty or not
specified along with the 'secure' field, it's handled properly by the
server, accepted by the browser, etc. strange that not specifying it
helps since u'd want ur script to run regardless of the server config
and as long as u can set certain parameters and control whether it
applies to subdomains or the primary domain.
set-cookie2 supports the port directive (http://www.faqs.org/rfcs/rfc2965.html)
Port[="portlist"]
dunno about implementation or browser support.
it would be good if the php handled this either using set-cookie2 or
stripping it from the domain...similar behaviour to when it's not
specified.
a comment was posted about this on the setcookie page
(http://php.net/manual/en/function.setcookie.php#36202) which i think
should be added to the function docs.
anirudh
--
]#
Anirudh Dutt
....pilot of the storm who leaves no trace
like thoughts inside a dream
--- End Message ---
