[PHP] Environment variables in php.ini
Hello, I have a Linux shared hosting environment with PHP running over CGI. With CGI I can't use httpd.conf or .htaccess files for PHP related parameters, so all the parameters should be given in one central php.ini file, AFAIK. So how can I give parameters, in effect, like the ones below? error_log = $HOME/php_error.log session.referer_check = $DOMAIN_NAME open_basedir = "$HOME:/usr/lib/php:/usr/local/lib/php:/tmp" session.save_path = $HOME/sessions With PHP module SAPI I would have overridden them in httpd.conf VirtualHost directive with hard coded values. There, I don't have to use variables as every vhost has its own VirtualHost section. But I don't know how to do it (or if it is possible at all) in CGI mode. Actually I did find a raw solution: Put a custom php.ini in each virtual host's Doc_Root. But I don't really want to allow virtual hosts each having a custom php.ini in their home directories, as that solution has several serious drawbacks, like: - No server/security policies can be enforced, - An intruder can change the local php.ini and remove all the security measures, - Hundreds of php.ini files strewn around can easily lead to chaos, - etc. Is it possible at all to use environment variables in php.ini, or is there any other solution to the problem above? Thank you. -- Abdullah Ramazanoglu aramazan ÄT myrealbox D0T cöm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: Environment variables in php.ini
Tijnema ! dedi ki: > On 3/30/07, Abdullah Ramazanoglu <[EMAIL PROTECTED]> wrote: --8<-- >> Is it possible at all to use environment variables in php.ini, or is >> there any other solution to the problem above? > It probably is possible, but you could just use a php.ini in each > userdir, but give it only access to the user PHP is running on. > > Tijnema That's probably what I'm going to do for the time being, though it will have to be an all or nothing approach for my customers. I.e. if they have write access to their private php.ini, then they'll have too much freedom, if they have just read access to php.ini then they'll have to manage in a frozen php environment. I would miss the php_flag and php_value features of module-PHP. Still looking for an ultimate solution. Thank you and regards -- Abdullah Ramazanoglu aramazan ÄT myrealbox D0T cöm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: Environment variables in php.ini
Jim Lucas dedi ki: > Abdullah Ramazanoglu wrote: --8<-- >> Is it possible at all to use environment variables in php.ini, or is >> there any other solution to the problem above? >> >> Thank you. > > Read this: > > http://us3.php.net/manual/en/configuration.php#configuration.file > > You can put a file in any other these locations that will be read by the > cgi when it is started. > > my suggestion would be to use a single php.ini file in a global location. > Then symlink a php.ini to there home directory or web root. > > Then set perms on the single global file such that only you can write to > it, but everybody can read > it. This should work for you. That was also my first inclination but I had to abandon it, because then I couldn't give different parameters for different virtual hosts. For instance currently I (have to) centrally use "error_log=php_error.log" and this causes a "php_error.log" been created everywhere (as I can't give absolute address, each php script creates a log in the directory it resides in.) If only I would have been able to give something to the effect of "php_error=$HOME/php_error.log" then every user would've had only one log file. Another drawback with central read-only php.ini is that users won't be able to tweak php.ini to certain extent (but not much - just like php_flag and php_value). With cgi-php, users are either too restricted (r/o php.ini) or too free (r/w php.ini). Thanks and regards -- Abdullah Ramazanoglu aramazan ÄT myrealbox D0T cöm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] php-cli vs python
Hello, I'm already (going to) use php for web based development. Shell scripting and compiled languages have their own places, but there's also a place for a high level scripting language. While people usually use python (for higher level and perl for lower level tasks) for this, I really wonder whether this would be worthwhile for me. I have just cursory info about python, and I'm by no means a php expert. So I can't reliably compare the two, but my rationale so far is simple: If php5, with its enhanced object oriented features and rich libraries is on par with python on the command line, then wouldn't it make better sense for me to use php for both web and cli/gui development? Nevertheless, I can't ignore the fact that people do use python almost exclusively for high level CLI/GUI scripting. Where's the catch? What's the top 3 killer features of python against php (and vice versa)? Any ideas, pointers, analysis, insights are most welcome. This is a rather strategical crossroads for me, and I'd very much like to make an informed decision. Thank you and kind regards. -- Abdullah Ramazanoglu aramazan ÄT myrealbox D0T cöm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: php-cli vs python
Chris dedi ki: > Abdullah Ramazanoglu wrote: --8<-- > Personally I'd stick to one or the other for the whole project, you'll > save yourself a lot of headaches in the future. Thank you Chris, for the insight. The more I think about it, the closer I get to the same conclusion. I've already made up my mind for php in web based development. Also, I'm still unable to find a dramatic disadvantage of php against python on the command line. What's more, I'm actually more of a sysadmin than a dedicated application programmer. So I can't afford to put more or less similar languages of the same league under my belt. Kind regards, -- Abdullah Ramazanoglu aramazan ÄT myrealbox D0T cöm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: Re: php-cli vs python
Daniel Brown dedi ki: > On 6/7/07, Man-wai Chang <[EMAIL PROTECTED]> wrote: --8<-- > Interesting reading: > http://wiki.w4py.org/python-vs-php.html Really interesting. It was a relief for me to see that even a somewhat biased document written by python champions didn't reveal serious advantages over php enough to consider dual language programming. However, there's a general perception of php as a "web-only" language, and all the comparisons I find -this one included- end up comparing the two as web programming languages. What I really need is a comparison regarding pure cli or gui projects. I found one intersting item though: Under the "What does Python have that PHP doesn't?" header, there's a bullet stating that "support for all major GUI frameworks". I know that both php and python have support for gtk. Am I to understand from this statement that python has also support for qt? Kind regards, -- Abdullah Ramazanoglu aramazan ÄT myrealbox D0T cöm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: File Upload - post_max_size and upload_max_filesize in GBs
Sukhwinder Singh dedi ki: --8<-- > I have read. I have been trying to find out way for last two days. > I can say about jupload and how it seems to work. > It uploads file to server in a temporary directory. > It has postURL parameter. Then it POSTS the data to php file. > Because it POSTS, the php configuration values comes into question. > > Here is an example: > > Settings in php.ini are 50M for upload_max_fisesize and 50M for > post_max_size. > I used japplet and uploaded a 51.89 MB file. > > This is what is in error log. > > [08-Jun-2007 03:06:29] PHP Warning: POST Content-Length of 54414946 > [bytes > exceeds the limit of 52428800 bytes in Unknown on line 0 Sorry but I couldn't follow. If I understood correctly, there's 50M (or 4G, for that matter) data, and there's say 5K metadata. First, java applet uploads the bulk data over ftp to a temp directory on the server (employing the ftp service running on the server - not apache/php). If/when the bulk data transfer completes successfully, then the java applet needs to POST the 5K metadata over http to php. Up to this point I can follow. But in your example, the java applet transfers the bulk data itself -not metadata- a second time, POSTing it to php? If so, then the applet you use (or the parameters it's been passed) should be broken, I guess. Kind regards, -- Abdullah Ramazanoglu aramazan ÄT myrealbox D0T cöm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: high-bit characters
WeberSites LTD dedi ki:
> I'm trying to validate an RSS feed and getting errors about "high-bit
> characters".
> How can I check if a string contains any high-bit characters?
if (preg_match("/[\x80-\xff]/", $string)) {
# high-bit char found
} else {
# no high-bit char
}
--
Abdullah Ramazanoglu
aramazan ÄT myrealbox D0T cöm
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] RE: Re: high-bit characters
WeberSites LTD dedi ki:
> Thanks, I'll check this out.
>
> Till now I managed to get the result I wanted with :
>
> for ($i=0 ; $i < strlen($post_text) ; $i++) {
> $chr = $post_text{$i};
> $ord = ord($chr);
> if (($ord<32 or $ord>126) and ($ord != 13) and ($ord !=
> 10)){
> Echo "BAD CHAR is : " . $ord;
> break;
> }
> }
> ?>
My suggestion finds high-bit characters (127-255), but you need to find
printable characters with the exception of \n and \r. So my suggestion
won't work for you, I'm afraid. Perhaps you want something like below?
$bad_string_flag = ! ctype_print(strtr($string, "\n\r", " "));
>From the docs, it seems that replacement string in strtr cannot be null for
correct operation, so I've used double blanks (or use any chars,
e.g. "NR"). The strtr part feels a bit clumsy, but you might be able to
find a better way in "XVII. Character Type Functions" or "CLXI. String
Functions" (PHP Manual).
Kind regards,
Abdullah
>
>
> berber
>
> -Original Message-
> From: news [mailto:[EMAIL PROTECTED] On Behalf Of Abdullah Ramazanoglu
> Sent: Friday, June 08, 2007 11:43 PM
> To: php-general@lists.php.net
> Subject: [PHP] Re: high-bit characters
>
> WeberSites LTD dedi ki:
>
>> I'm trying to validate an RSS feed and getting errors about "high-bit
>> characters".
>> How can I check if a string contains any high-bit characters?
>
> if (preg_match("/[\x80-\xff]/", $string)) {
> # high-bit char found
> } else {
> # no high-bit char
> }
>
> --
> Abdullah Ramazanoglu
> aramazan ÄT myrealbox D0T cöm
>
> --
> PHP General Mailing List (http://www.php.net/) To unsubscribe, visit:
> http://www.php.net/unsub.php
>
--
Abdullah Ramazanoglu
aramazan ÄT myrealbox D0T cöm
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] RE: RE: Re: high-bit characters
WeberSites LTD dedi ki:
> Thanks, I'll have a look at it.
>
> I do want to allow some chars so I'm trying to replace them
> like this :
>
> $post_text=str_replace(chr(146),"'",$post_text);
>
> or
>
> $post_text=str_replace("","'",$post_text);
>
>
> However, it seems that str_replace does not actually replace
> the chars cause they still end up in the output.
>
> any idea?
It works for me:
echo str_replace(chr(146),"'",str_repeat("X".chr(146)."Y", 10));
X'YX'YX'YX'YX'YX'YX'YX'YX'YX'Y
Also: (should be lighter and faster than str_replace, I think)
echo strtr(str_repeat("X".chr(146)."Y", 10), chr(146), "'");
X'YX'YX'YX'YX'YX'YX'YX'YX'YX'Y
It might be related to your input - perhaps not 8-bit clean? Perhaps
preprocessed in some way through the pipe (network, linux, apache, php.ini
settings, etc.) before it reached your script? Hard to guess.
I would've written (in binary safe way) the input to a temp file and then
inspected it via hexdump, less, hexedit etc.
Kind regards,
--
Abdullah Ramazanoglu
aramazan ÄT myrealbox D0T cöm
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: Re: Re: php-cli vs python
Crayon Shin Chan dedi ki: > On Friday 08 June 2007 04:10, Abdullah Ramazanoglu wrote: > >> I found one intersting item though: Under the "What does Python have >> that PHP doesn't?" header, there's a bullet stating that "support for >> all major GUI frameworks". I know that both php and python have support >> for gtk. Am I to understand from this statement that python has also >> support for qt? > > Yes, it's called PyQT. For purely non-web work Python beats PHP hands > down. Plus it runs on more platforms. Thank you Crayon, PyQT seems really cool (I like Qt better :) For the part regarding Python beating PHP on the CLI/GUI, I've been thinking about this. I might be totally wrong, but I tend to view it like this: In order to make a long term decision about a language, I dissect the core language itself and its "family" (libraries, dev tools, etc. but mainly libraries). All languages evolve, but their starting point both gives them a head start in their particular problem domain, and also it defines how far the language can evolve into other problem domains. E.g. it's difficult for Perl to evolve into a PHP-like web programming language. Now, with Python and PHP, I think both evolves into the other's problem domain. How successful and how far they will be in doing this, might revolve around 3 points: 1. Their core quality (language specs) 2. The distance of their starting point to the point they evolve into. 3. Library support (coupled with gaining popularity in the target domain) As for the 1st point, I can't talk much, as I'm a Python illiterate and PHP newbie. Nevertheless, there are subjective opinions about Python being "beautiful", "cool", "elegant" etc. but they are not very quantitative. I'm yet to see a quantitative solid example demonstrating the advantages of Python against PHP regarding their core language qualities. Admittedly, there are some annoying features of PHP, the most annoying one being its "dynamic" typing (opposed to "weak" typing). Sometimes I need to fight against PHP to protect my data from being spoiled by PHP's high-level eager assumptions. But I guess it's the way it's supposed to be in any high level language - be it PHP or Python. PHP is not C, neither is Python. As for the second point, PHP seems to have an advantage over Python here, because (CLI/GUI library support aside) it's quite a decent language to write programs for general purpose problem domain. At least it satisfies my current expectations in that regard. So, while I find PHP core an adequate language for general purpose programming, I don't know how satisfying Python is in web programming domain. I know from a distance that it has issues like lacking "safe-mode" equivalent, built-in sessions, etc. But given enough evolution and libraries, I'm sure Python would be a contender in web programming domain. This brings me to the third point, library support and developer popularity. Both feeds back the other: Library support encourages developers to use the language in other domains, and developer popularity (or demand) paves the way for library support to get better and better, thus it can evolve as far as core language specs don't become a hindrance. Currently, CLI/GUI library support for PHP is not as powerful as Python's. I accept this and I expect this: PHP-CLI is just taking off. Currently its usage is also low (I'm the sole bug submitter for php-newt library) but I'm trying to see what it would be like in 5 years' time. If CLI/GUI library support gets on par with Python's, then what's the point for me to (fail to) master two similar languages instead of really mastering just one? It might be said that then I can equally start with Python, using the same logic. True. But currently, I perceive PHP as more satisfying on the CLI than Python on the web. So I perceive I can more successfully use PHP as a dual domain language than Python. So, presuming that both languages will evolve quite close to each other in the future, I can start with which one better satisfies my current needs. That's roughly why I'm more and more in favor of PHP. At least I think I can wait till I can justify to myself adopting multiple similar, high-level scripting languages. Sure, I'm concerned (much concerned) with non-web library support and developer adoption of PHP - just like I'd have been concerned with Python's web-support if I were going with Pyhon. As I've said earlier, this is all IMHO, and I might be totally wrong. Kind regards, -- Abdullah Ramazanoglu aramazan ÄT myrealbox D0T cöm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: Re: Re: Re: php-cli vs python
Nathan Nobbe dedi ki:
>> Admittedly, there are some annoying features of PHP, the most
>> annoying one being its "dynamic" typing (opposed to "weak" typing).
>
> I think its worth mentioning that 'dynamic' and 'weak' typing both refer
> to type checking, yet they refer to different aspects of type checking.
> a lanuguage is either dynamically or statically typed and either weakly
> or strongly typed, going by wikipedia:
> http://en.wikipedia.org/wiki/Type_checking#Type_checking
>
> and PHP is supposedly dynamically, weakly typed
> http://en.wikipedia.org/wiki/Php
My sloppy terminology use. Still not sure about the precise terminology,
but what I meant might be called as "unavoidable dynamic casting". For
instance, I once wanted to XOR a 128 bit binary string variable with a 128
bit binary constant string. Unable to express a binary string in a
straightforward way, I resorted to "pack" it like this:
$key = pack("N*", 0x12345678, 0x9abcdef0, 0x87654321, 0x0fedcba9);
Well, second and third 32-bit hex values were automatically converted by
PHP to float, before packing, because PHP tries to cast them into signed
32-bit integers, which can't be represented with, as they're above
0x7fff (2^31-1). So, PHP casts them to floats. As a workaround I had
to use modulo-8 values for the top hex digits. (E.g. 0x1abcdef0 instead of
0x9abcdef0).
No way to say "Just take these bytes and pack them together, as is". Every
operation goes through PHP's own type juggling pipe. I can do explicit
casting, but not always - as in the example above. (It's possibly just my
lack of grip on PHP).
I wish PHP6 would bring along a feature to arbitrarily control or disable
dynamic casting. Without auto-casting, treating everything as byte
strings. E.g. if the user says
$x = "A" + 5;
and if auto casting is disabled, then just adding their internal
representations (0x41 + 0x05 giving 0x46) like an assembler. Sometimes I
want to take all the responsibility of disabling typing, and instruct
PHP "please do it as is, and let me worry if it makes sense or not".
Perhaps there's already a way to do this?..
Kind regards,
--
Abdullah Ramazanoglu
aramazan ÄT myrealbox D0T cöm
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: Re: Re: Re: php-cli vs python
Abdullah Ramazanoglu dedi ki:
> $key = pack("N*", 0x12345678, 0x9abcdef0, 0x87654321, 0x0fedcba9);
>
> Well, second and third 32-bit hex values were automatically converted by
> PHP to float, before packing, because PHP tries to cast them into signed
> 32-bit integers, which can't be represented with, as they're above
> 0x7fff (2^31-1). So, PHP casts them to floats. As a workaround I had
> to use modulo-8 values for the top hex digits. (E.g. 0x1abcdef0 instead
> of 0x9abcdef0).
This is interestingly incorrect. I've just rechecked it and seen that
pack "N" works with unsigned integers as documented.
I remember it packing large (>2^31-1) integers into float, but I don't
remember my earlier test details. Obviously I've done something wrong in
my earlier trials.
Kind regards,
--
Abdullah Ramazanoglu
aramazan ÄT myrealbox D0T cöm
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: Keeping file pointers open after script end
Tijnema dedi ki: > Is there any way to keep a file pointer open after script is finished, > so that it can be access later, by passing it through session? ftell() / fseek() ? Kind regards, -- Abdullah Ramazanoglu aramazan ÄT myrealbox D0T cöm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: php-cli vs python
Richard Lynch dedi ki: > I use PHP extensively for command line processing. > > Why not just try it and see if it works well for you? I will :) -- Abdullah Ramazanoglu aramazan ÄT myrealbox D0T cöm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: pack vs. serialize
Nathan Nobbe dedi ki: > all, > > i have recently stumbled upon the > pack<http://www.php.net/manual/en/function.pack.php>method. > can this be used as a substitute for > serialize<http://www.php.net/manual/en/function.serialize.php> > ? > if so, is there any rationalization for this; like would it perhaps > create a more > compact representation of the data or run more quickly? > it looks like pack cannot be used on object as i didnt see object in the > format listing; > what would be a typical application of the pack method? I've not used serialize(), but I think it packs its input into some proprietary (internal) format best suited to handle as a single entity (pass it to-fro, store it in database, etc.). Ergo, a serialized entity cannot be used as it is - you need to unserialize it back before use. OTOH, pack() returns the internal binary representation of its input as a binary string. This may not always be the optimal way to handle a given collection of data as in the case for serialize(), but it enables you to access, use and manipulate internal representations of the data, be it just a single variable or an assorted structure. I once used pack to obtain a 128 bit long binary string (xor key for rudimentary file encryption) by packing four 32-bit integers into a binary string and then using it as the xor key. (FWIW, bitwise operations work both on integers and "strings" - binary or otherwise.) Kind regards, -- Abdullah Ramazanoglu aramazan ÄT myrealbox D0T cöm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
