php-general Digest 8 Jan 2008 01:37:22 -0000 Issue 5222
Topics (messages 266837 through 266862):
Re: First stupid post of the year. [SOLVED]
266837 by: tedd
266838 by: Zoltán Németh
266840 by: Robert Cummings
266846 by: tedd
266850 by: tedd
utf-8 in $_POST
266839 by: Olav Mørkrid
266842 by: pobox.verysmall.org
266844 by: mike
266852 by: Olav Mørkrid
266854 by: mike
266861 by: Larry Garfield
Re: PHTML files showing as blank pages
266841 by: Andy Smith
iphone.facebook.com PHP inquiry
266843 by: Steve Finkelstein
266845 by: mike
266847 by: Steve Finkelstein
266848 by: mike
is_executable() ???
266849 by: Al
266858 by: Chris
266859 by: Richard Lynch
global address collection
266851 by: tedd
266853 by: Nathan Nobbe
266857 by: Richard Heyes
./configure APC problems with 3.0.16 and what happened to
--enable-apc-pthreadmutex???
266855 by: steve
266856 by: steve
passing _GET values to _POST
266860 by: Mary Anderson
266862 by: Richard Lynch
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:
[EMAIL PROTECTED]
----------------------------------------------------------------------
--- Begin Message ---
At 12:03 PM +0100 1/7/08, Nisse Engström wrote:
How does the following pages compare? The display
should be identical:
<http://luden.se/test/t-1252.html>
<http://luden.se/test/t-utf8.html>
Nisse:
No, there is quite a difference depending upon
the text encoding used in my browser (Safari).
For example, using UTF-8
<http://luden.se/test/t-1252.html>
produces nothing but repeating <?> (black diamond with question mark).
Where as:
<http://luden.se/test/t-utf8.html>
Shows all the code-points correctly.
---
Using Western (ISO Latin 1)
http://luden.se/test/t-1252.html
is correct, but
<http://luden.se/test/t-utf8.html>
is gibberish.
---
Using Western (Mac OS Roman)
http://luden.se/test/t-1252.html
is almost correct (it has an Apple logo).
and
<http://luden.se/test/t-utf8.html>
is gibberish.
--
So, the browser wars move on to text encoding.
Cheers,
tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com
--- End Message ---
--- Begin Message ---
2008. 01. 7, hétfő keltezéssel 10.29-kor tedd ezt írta:
> At 12:03 PM +0100 1/7/08, Nisse Engström wrote:
> >How does the following pages compare? The display
> >should be identical:
> >
> ><http://luden.se/test/t-1252.html>
> ><http://luden.se/test/t-utf8.html>
>
> Nisse:
>
> No, there is quite a difference depending upon
> the text encoding used in my browser (Safari).
>
> For example, using UTF-8
>
> <http://luden.se/test/t-1252.html>
>
> produces nothing but repeating <?> (black diamond with question mark).
>
> Where as:
>
> <http://luden.se/test/t-utf8.html>
>
> Shows all the code-points correctly.
>
> ---
>
> Using Western (ISO Latin 1)
>
> http://luden.se/test/t-1252.html
>
> is correct, but
>
> <http://luden.se/test/t-utf8.html>
>
> is gibberish.
>
>
> ---
> Using Western (Mac OS Roman)
>
> http://luden.se/test/t-1252.html
>
> is almost correct (it has an Apple logo).
>
> and
>
> <http://luden.se/test/t-utf8.html>
>
> is gibberish.
>
> --
however, on firefox with encoding auto-detection both page looks
correctly and the same.
greets
Zoltán Németh
>
> So, the browser wars move on to text encoding.
>
> Cheers,
>
> tedd
>
> --
> -------
> http://sperling.com http://ancientstones.com http://earthstones.com
>
--- End Message ---
--- Begin Message ---
All of these look the same for me in Opera under Linux. Character sets
are not a browser war issue, they're a character set/font issue. Just
because a character set supports a character, doesn't mean the character
font exists.
Cheers,
Rob.
On Mon, 2008-01-07 at 10:29 -0500, tedd wrote:
> At 12:03 PM +0100 1/7/08, Nisse Engström wrote:
> >How does the following pages compare? The display
> >should be identical:
> >
> ><http://luden.se/test/t-1252.html>
> ><http://luden.se/test/t-utf8.html>
>
> Nisse:
>
> No, there is quite a difference depending upon
> the text encoding used in my browser (Safari).
>
> For example, using UTF-8
>
> <http://luden.se/test/t-1252.html>
>
> produces nothing but repeating <?> (black diamond with question mark).
>
> Where as:
>
> <http://luden.se/test/t-utf8.html>
>
> Shows all the code-points correctly.
>
> ---
>
> Using Western (ISO Latin 1)
>
> http://luden.se/test/t-1252.html
>
> is correct, but
>
> <http://luden.se/test/t-utf8.html>
>
> is gibberish.
>
>
> ---
> Using Western (Mac OS Roman)
>
> http://luden.se/test/t-1252.html
>
> is almost correct (it has an Apple logo).
>
> and
>
> <http://luden.se/test/t-utf8.html>
>
> is gibberish.
>
> --
>
> So, the browser wars move on to text encoding.
>
> Cheers,
>
> tedd
>
> --
> -------
> http://sperling.com http://ancientstones.com http://earthstones.com
>
--
...........................................................
SwarmBuy.com - http://www.swarmbuy.com
Leveraging the buying power of the masses!
...........................................................
--- End Message ---
--- Begin Message ---
At 4:36 PM +0100 1/7/08, Zoltán Németh wrote:
2008. 01. 7, hétf keltezéssel 10.29-kor tedd ezt írta:
however, on firefox with encoding auto-detection both page looks
correctly and the same.
greets
Zoltán Németh
Not that you are claiming otherwise, but FF will
render the pages incorrectly if the text encoding
isn't correctly set -- and that's the point.
Look at this in FF with text encoding set to ISO-8859:
http://luden.se/test/t-utf8.html
Cheers,
tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com
--- End Message ---
--- Begin Message ---
At 10:41 AM -0500 1/7/08, Robert Cummings wrote:
Character setsare not a browser war issue,
they're a character set/font issue. Just
because a character set supports a character, doesn't mean the character
font exists.
Cheers,
Rob.
Rob:
What I meant by "browser wars" was that there is
a different between how browsers render different
text encodings -- this is a fact -- there is a
difference. For example, the "Extended" ASCII
codes (never approved by ASCII) shows many
characters differently depending on browser
encoding. Apple even has it's own logo appearing
for DEC 240 (F0 HEX) for it's encoding. I can
provide even more examples of differences if
necessary, but one should be enough.
Additionally, browsers absolutely render urls
differently depending on encoding. Just look at
the IDNS encoding PUNYCODE for that -- here's
proof:
http://xn--19g.com
In Safari (both Mac and Windows) the url will be
shown as .com (square root dot dom) whereas in
IE (all versions) it will be show in PUNYCODE,
namely xn--19g.com
Note -- both OS's clearly have the square root
symbol in their font set. So this is NOT an issue
of IF the character exist within the font
(charset) because the character IS present.
I know the reasons behind their decisions to do
what they did, but the fact remains there is a
difference, as I said.
Cheers,
tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com
--- End Message ---
--- Begin Message ---
hello
does php have any built-in functions to convert post data from
whatever format it arrives in to whatever format i wish?
example:
i use iso-8859-1 internally, and even specify
accept-charset=iso-8859-1 in my html, but some browsers (phones) send
utf-8 anyway.
do i have to manually check if CONTENT_TYPE says "utf-8" and then
convert the $_POST array elements one by one, or does php have any
built-in functions to ease this?
--- End Message ---
--- Begin Message ---
Olav Mørkrid wrote:
hello
does php have any built-in functions to convert post data from
whatever format it arrives in to whatever format i wish?
example:
i use iso-8859-1 internally, and even specify
accept-charset=iso-8859-1 in my html, but some browsers (phones) send
utf-8 anyway.
do i have to manually check if CONTENT_TYPE says "utf-8" and then
convert the $_POST array elements one by one, or does php have any
built-in functions to ease this?
That's interesting question.
Do you generate the pages, respectively do you specify something like this -
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
My experience is that this does not affect only the displayed
characters, but the way the form fields are transported.
But perhaps I am wrong,
Iv
--- End Message ---
--- Begin Message ---
> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
>
> My experience is that this does not affect only the displayed
> characters, but the way the form fields are transported.
>
> But perhaps I am wrong,
> Iv
This works for me as well.
Put in utf-8 and you should be good to go.
You don't -technically- need to even change your database fields or
anything; MySQL will take the utf-8 content and treat it like normal
binary content.
(However, if you want to modify the data in MySQL, then you might want
to make sure you have all the right character sets and stuff...)
I've had 100% success with just inserting and selecting info back and
forth from MySQL and displaying it on the page, with the proper <meta>
tag. Works like a charm in all languages attempted - English, Chinese
(both Simplified and Traditional), Russian, etc... it will look funky
if you view it directly in MySQL command line client or if you forget
the utf-8 tag though (unless your TERM + column and connection is set
properly)
--- End Message ---
--- Begin Message ---
i specify iso-8859-1 in both header and body:
<meta http-equiv="Content-type" content="text/html; charset=iso-8859-1"/>
<form action="/" method="post" accept-charset="iso-8859-1">
if two different people post the norwegian phrase "Godt nytt år"
(happy new year), it may appear in the following variations:
[CONTENT_TYPE] => application/x-www-form-urlencoded;charset=iso-8859-1
$_POST["input"] = "Godt nytt år"
[CONTENT_TYPE] => application/x-www-form-urlencoded;charset=utf-8
$_POST["input"] = "Godt nytt år"
i was just wondering if php had some setting or function that would
make it auto-convert $_POST data into one specific encoding. otherwise
i seem forced to do something like this in the beginning of my php
script:
if(ereg("utf-8", $_SERVER["CONTENT_TYPE"])) {
foreach($_POST as $key => $value)
$_POST["key"] = convert_utf8_to_iso8859($value);
}
--- End Message ---
--- Begin Message ---
maybe look at iconv functions
but the <meta> content-type is the only thing i set, and it works 100%
fine. all javascripts, forms, etc. inherit it from the looks of it
properly.
On 1/7/08, Olav Mørkrid <[EMAIL PROTECTED]> wrote:
> i specify iso-8859-1 in both header and body:
>
> <meta http-equiv="Content-type" content="text/html; charset=iso-8859-1"/>
> <form action="/" method="post" accept-charset="iso-8859-1">
>
> if two different people post the norwegian phrase "Godt nytt år"
> (happy new year), it may appear in the following variations:
>
> [CONTENT_TYPE] => application/x-www-form-urlencoded;charset=iso-8859-1
> $_POST["input"] = "Godt nytt år"
>
> [CONTENT_TYPE] => application/x-www-form-urlencoded;charset=utf-8
> $_POST["input"] = "Godt nytt år"
>
> i was just wondering if php had some setting or function that would
> make it auto-convert $_POST data into one specific encoding. otherwise
> i seem forced to do something like this in the beginning of my php
> script:
>
> if(ereg("utf-8", $_SERVER["CONTENT_TYPE"])) {
> foreach($_POST as $key => $value)
> $_POST["key"] = convert_utf8_to_iso8859($value);
> }
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--- End Message ---
--- Begin Message ---
I have to ask... WHY are you forcing ISO-8859-1? If anything, you should be
forcing UTF-8. Then you can send, receive, and store data in UTF-8 ad cover
most human languages without having to change character set.
On Monday 07 January 2008, Olav Mørkrid wrote:
> i specify iso-8859-1 in both header and body:
>
> <meta http-equiv="Content-type" content="text/html; charset=iso-8859-1"/>
> <form action="/" method="post" accept-charset="iso-8859-1">
>
> if two different people post the norwegian phrase "Godt nytt år"
> (happy new year), it may appear in the following variations:
>
> [CONTENT_TYPE] => application/x-www-form-urlencoded;charset=iso-8859-1
> $_POST["input"] = "Godt nytt år"
>
> [CONTENT_TYPE] => application/x-www-form-urlencoded;charset=utf-8
> $_POST["input"] = "Godt nytt år"
>
> i was just wondering if php had some setting or function that would
> make it auto-convert $_POST data into one specific encoding. otherwise
> i seem forced to do something like this in the beginning of my php
> script:
>
> if(ereg("utf-8", $_SERVER["CONTENT_TYPE"])) {
> foreach($_POST as $key => $value)
> $_POST["key"] = convert_utf8_to_iso8859($value);
> }
--
Larry Garfield AIM: LOLG42
[EMAIL PROTECTED] ICQ: 6817012
"If nature has made any one thing less susceptible than all others of
exclusive property, it is the action of the thinking power called an idea,
which an individual may exclusively possess as long as he keeps it to
himself; but the moment it is divulged, it forces itself into the possession
of every one, and the receiver cannot dispossess himself of it." -- Thomas
Jefferson
--- End Message ---
--- Begin Message ---
Hi All,
Ok, I have resolved the problem! Interestingly from the index.phtml page I
was still unable to get any info even
after setting the display errors options as suggested by Brady. I tried
connecting direct to some other random
.phtml files included in the CDRTool app and I started getting errors
regarding missing files. The solution turned
out that there were many "pear" module dependencies that weren't mentioned
in the installation and requirements
documents for CDRTool (which simply stated PHP was required). Anyway I added
the modules one by one
depending on the error message I was seeing and now I can connect to the
index.phtml page too.
Thanks to those who replied,
cheers Andy.
----- Original Message -----
From: "Brady Mitchell" <[EMAIL PROTECTED]>
To: "A.smith" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Sunday, January 06, 2008 12:37 AM
Subject: Re: [PHP] PHTML files showing as blank pages
On Jan 5, 2008, at 639AM, A.smith wrote:
I'm having a problem getting .phtml files to display in a web browser.
I
can successfully display a test.php page as per PHP install instructions
but
the phtml files show up blank
(in firefox or IE).
A blank page often means that there's an error of some kind, but error
reporting is turned off.
Put the following code in the file that's giving you problems to turn on
errors, then reload the file in your browser to see what you get:
ini_set('display_errors',1);
Brady
--- End Message ---
--- Begin Message ---
Hi folks,
Probably the most impressive application I've run into for the iPhone has to
be Facebook's implementation. I'm looking for ways to improve my application
to be as responsive as theirs. Unfortunately it has quite a way to go. Does
anyone know how this form of 'routing' works?
For instance the home page for iphone.facebook.com looks something like:
http://iphone.facebook.com/#home.php
then if you click on profile it'll route you to something that looks like
http://iphone.facebook.com/#profile.php?id=XXXX
Is this actually 'leaving' the page and requesting profile.php? I'm
completely confused with the hash mark in front of the PHP file and the
mechanics behind this style. It seems to be extremely well implemented
though and I'd like to learn more about it. I'm having a ton of issues with
my application now where Ajax calls randomly do not get sent to the server.
I haven't figured out why, maybe mobile safari is caching request URLs. But
I'm looking to rebuild parts of the architecture to get it to work, and
would love to understand the mechanism being used above.
Does anyone know what is going on with the browser and HTTP requests with
the methodology listed above? Any further reading?
Thanks!
- sf
--- End Message ---
--- Begin Message ---
It's probably using IUI (the iPhone UI CSS/JS that Joe Hewitt created,
now being maintained at http://code.google.com/p/iui/) which allows
you to request the page to be loaded via AJAX based on how you setup
the link.
<a href="foo.php">this will load via AJAX</a>
<a href="foo.php" target="_self">this will load like a normal page link</a>
This is how I *believe* it works, I just implemented IUI partially on
a site at work a few days ago and the final thing for me to work out
the kinks is whether or not to load certain pages using the AJAX
method (and show the cute little "loading" circle thing) or reload the
entire page.
Remember it's all just Javascript trickery with CSS that works great
on Safari browsers (and works almost identical actually now in
Firefox...)
It's very easy to implement, I had some initial confusion too how it
routes the requests but I think I figured it out there ^^
On 1/7/08, Steve Finkelstein <[EMAIL PROTECTED]> wrote:
> Hi folks,
>
> Probably the most impressive application I've run into for the iPhone has to
> be Facebook's implementation. I'm looking for ways to improve my application
> to be as responsive as theirs. Unfortunately it has quite a way to go. Does
> anyone know how this form of 'routing' works?
>
> For instance the home page for iphone.facebook.com looks something like:
>
> http://iphone.facebook.com/#home.php
>
> then if you click on profile it'll route you to something that looks like
>
> http://iphone.facebook.com/#profile.php?id=XXXX
>
> Is this actually 'leaving' the page and requesting profile.php? I'm
> completely confused with the hash mark in front of the PHP file and the
> mechanics behind this style. It seems to be extremely well implemented
> though and I'd like to learn more about it. I'm having a ton of issues with
> my application now where Ajax calls randomly do not get sent to the server.
> I haven't figured out why, maybe mobile safari is caching request URLs. But
> I'm looking to rebuild parts of the architecture to get it to work, and
> would love to understand the mechanism being used above.
>
> Does anyone know what is going on with the browser and HTTP requests with
> the methodology listed above? Any further reading?
>
> Thanks!
>
> - sf
>
--- End Message ---
--- Begin Message ---
Thanks for the reply Mike.
I suppose ultimately I'd need to dig into the JavaScript (hopefully it's not
compressed) to figure out the PHP routing. I believe re-writing my
application with the framework would be quite extensive and just not
feasible at this particular point in time, although I should consider it in
the future if my application remains problematic and this is a solid
solution. The concept of calling back-end code via anchor tags though is
something I've never seen.
- sf
On 1/7/08, mike <[EMAIL PROTECTED]> wrote:
>
> It's probably using IUI (the iPhone UI CSS/JS that Joe Hewitt created,
> now being maintained at http://code.google.com/p/iui/) which allows
> you to request the page to be loaded via AJAX based on how you setup
> the link.
>
> <a href="foo.php">this will load via AJAX</a>
>
> <a href="foo.php" target="_self">this will load like a normal page
> link</a>
>
> This is how I *believe* it works, I just implemented IUI partially on
> a site at work a few days ago and the final thing for me to work out
> the kinks is whether or not to load certain pages using the AJAX
> method (and show the cute little "loading" circle thing) or reload the
> entire page.
>
> Remember it's all just Javascript trickery with CSS that works great
> on Safari browsers (and works almost identical actually now in
> Firefox...)
>
> It's very easy to implement, I had some initial confusion too how it
> routes the requests but I think I figured it out there ^^
>
>
>
> On 1/7/08, Steve Finkelstein <[EMAIL PROTECTED]> wrote:
> > Hi folks,
> >
> > Probably the most impressive application I've run into for the iPhone
> has to
> > be Facebook's implementation. I'm looking for ways to improve my
> application
> > to be as responsive as theirs. Unfortunately it has quite a way to go.
> Does
> > anyone know how this form of 'routing' works?
> >
> > For instance the home page for iphone.facebook.com looks something like:
> >
> > http://iphone.facebook.com/#home.php
> >
> > then if you click on profile it'll route you to something that looks
> like
> >
> > http://iphone.facebook.com/#profile.php?id=XXXX
> >
> > Is this actually 'leaving' the page and requesting profile.php? I'm
> > completely confused with the hash mark in front of the PHP file and the
> > mechanics behind this style. It seems to be extremely well implemented
> > though and I'd like to learn more about it. I'm having a ton of issues
> with
> > my application now where Ajax calls randomly do not get sent to the
> server.
> > I haven't figured out why, maybe mobile safari is caching request URLs.
> But
> > I'm looking to rebuild parts of the architecture to get it to work, and
> > would love to understand the mechanism being used above.
> >
> > Does anyone know what is going on with the browser and HTTP requests
> with
> > the methodology listed above? Any further reading?
> >
> > Thanks!
> >
> > - sf
> >
>
--- End Message ---
--- Begin Message ---
It's -very- easy to use.
Just strip your pages down and let the device do a lot of the work
(via the IUI CSS/JS) - I converted our WordPress-based site in maybe
15-20 minutes on my first try.
It was tricky when loading up the subpages, I figured out the
difference between the full-loading pages and the AJAX-requested
pages. The AJAX ones you don't call a header/footer - that seems to
make the device "ignore" the page load. So those pages loaded via
simple <a href="foo.php">ajax call</a> should be just a page fragment
essentially; it replaces the body of the page, but not the entire
page.
On 1/7/08, Steve Finkelstein <[EMAIL PROTECTED]> wrote:
> Thanks for the reply Mike.
>
> I suppose ultimately I'd need to dig into the JavaScript (hopefully it's not
> compressed) to figure out the PHP routing. I believe re-writing my
> application with the framework would be quite extensive and just not
> feasible at this particular point in time, although I should consider it in
> the future if my application remains problematic and this is a solid
> solution. The concept of calling back-end code via anchor tags though is
> something I've never seen.
>
> - sf
>
>
> On 1/7/08, mike <[EMAIL PROTECTED]> wrote:
> > It's probably using IUI (the iPhone UI CSS/JS that Joe Hewitt created,
> > now being maintained at http://code.google.com/p/iui/) which allows
> > you to request the page to be loaded via AJAX based on how you setup
> > the link.
> >
> > <a href="foo.php">this will load via AJAX</a>
> >
> > <a href="foo.php" target="_self">this will load like a normal page
> link</a>
> >
> > This is how I *believe* it works, I just implemented IUI partially on
> > a site at work a few days ago and the final thing for me to work out
> > the kinks is whether or not to load certain pages using the AJAX
> > method (and show the cute little "loading" circle thing) or reload the
> > entire page.
> >
> > Remember it's all just Javascript trickery with CSS that works great
> > on Safari browsers (and works almost identical actually now in
> > Firefox...)
> >
> > It's very easy to implement, I had some initial confusion too how it
> > routes the requests but I think I figured it out there ^^
> >
> >
> >
> > On 1/7/08, Steve Finkelstein <[EMAIL PROTECTED]> wrote:
> > > Hi folks,
> > >
> > > Probably the most impressive application I've run into for the iPhone
> has to
> > > be Facebook's implementation. I'm looking for ways to improve my
> application
> > > to be as responsive as theirs. Unfortunately it has quite a way to go.
> Does
> > > anyone know how this form of 'routing' works?
> > >
> > > For instance the home page for iphone.facebook.com looks something like:
> > >
> > > http://iphone.facebook.com/#home.php
> > >
> > > then if you click on profile it'll route you to something that looks
> like
> > >
> > > http://iphone.facebook.com/#profile.php?id=XXXX
> > >
> > > Is this actually 'leaving' the page and requesting profile.php? I'm
> > > completely confused with the hash mark in front of the PHP file and the
> > > mechanics behind this style. It seems to be extremely well implemented
> > > though and I'd like to learn more about it. I'm having a ton of issues
> with
> > > my application now where Ajax calls randomly do not get sent to the
> server.
> > > I haven't figured out why, maybe mobile safari is caching request URLs.
> But
> > > I'm looking to rebuild parts of the architecture to get it to work, and
> > > would love to understand the mechanism being used above.
> > >
> > > Does anyone know what is going on with the browser and HTTP requests
> with
> > > the methodology listed above? Any further reading?
> > >
> > > Thanks!
> > >
> > > - sf
> > >
> >
>
>
--- End Message ---
--- Begin Message ---
clearstatcache();
if(is_executable(PATH_TO_SOURCE_DIR . $filename)
{
code
}
Always returns true for:
foo.jpg
foo.php
foo.sh
And even if I feed it a non existing file.
I found one ref that said is_executable() doesn't work in safemode, seems dumb
if true.
If that's so, how can I test whether an uploaded file is executable?
I'm on a NIX with Apache, etc.
--- End Message ---
--- Begin Message ---
Al wrote:
clearstatcache();
if(is_executable(PATH_TO_SOURCE_DIR . $filename)
{
code
}
Always returns true for:
foo.jpg
foo.php
foo.sh
And even if I feed it a non existing file.
Really?
<?php
$file = 'blah.de.blah';
echo 'file exists: ' . is_file($file) . "\n";
echo 'is exec: ' . is_executable($file) . "\n";
?>
file exists:
is exec:
Check the permissions on those files through ftp or ssh. Are they 755 or
are they 644 ?
If they are 755 (or 775 or 777) then they are actually executable files.
Whether you get a valid result from that or not is entirely separate but
in *nix you could make a .txt file executable and it won't care.
--
Postgresql & php tutorials
http://www.designmagick.com/
--- End Message ---
--- Begin Message ---
is_executable() does not check whether a file's contents will do
something useful (or dangerous, depending on one's viewpoint) when you
execute the file.
It just checks if the file has been set as "executable" with
http://php.net/chmod
ANY file with ANY extension, or NO extension at all, can be an
executable on Un*x systems.
Your uploaded files should be chmod-ed to NOT be executable, in
addition to trying to catch any invalid data contents.
On Mon, January 7, 2008 11:30 am, Al wrote:
> clearstatcache();
> if(is_executable(PATH_TO_SOURCE_DIR . $filename)
> {
> code
> }
>
> Always returns true for:
> foo.jpg
> foo.php
> foo.sh
>
> And even if I feed it a non existing file.
>
> I found one ref that said is_executable() doesn't work in safemode,
> seems dumb
> if true.
>
> If that's so, how can I test whether an uploaded file is executable?
>
> I'm on a NIX with Apache, etc.
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/from/lynch
Yeah, I get a buck. So?
--- End Message ---
--- Begin Message ---
Hi:
What would be a good form (i.e., fields) for collecting global
addresses and phone numbers?
In other words, in the USA we ask for name, address, city, state,
zip, and phone number. What would be a global equivalent that could
cover all (or most) address and phone numbers?
Cheers,
tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com
--- End Message ---
--- Begin Message ---
On Jan 7, 2008 1:13 PM, tedd <[EMAIL PROTECTED]> wrote:
> Hi:
>
> What would be a good form (i.e., fields) for collecting global
> addresses and phone numbers?
>
> In other words, in the USA we ask for name, address, city, state,
> zip, and phone number. What would be a global equivalent that could
> cover all (or most) address and phone numbers?
i once had to assemble a mapping between several proprietary systems
address conventions and a domestic standard. i far as i recall, i found the
'official' info on the usps site.
i spent a couple of minutes looking there just now; although i found nothing
on international standards or recommendations, but further searching may
yield something useful.
-nathan
--- End Message ---
--- Begin Message ---
In other words, in the USA we ask for name, address, city, state, zip,
and phone number. What would be a global equivalent that could cover all
(or most) address and phone numbers?
Full name (optionally forename/surname)
Address 1
Address 2 (optional)
Address 3 (optional)
Town/City
County/State
Postal/Zip code
Country
Full international phone number (eg. 0044 1623 123456)
--
Richard Heyes
http://www.websupportsolutions.co.uk
Knowledge Base and HelpDesk software
that can cut the cost of online support
** NOW OFFERING FREE ACCOUNTS TO CHARITIES AND NON-PROFITS **
--- End Message ---
--- Begin Message ---
When configuring APC 3.0.16 I see this, which I don't recall seeing before:
checking dlfcn.h presence... no
configure: WARNING: dlfcn.h: accepted by the compiler, rejected by the
preprocessor!
configure: WARNING: dlfcn.h: proceeding with the compiler's result
checking for dlfcn.h... yes
Also --enable-apc-pthreadmutex no longer seems to work (it is no
longer in ./configure --help and in phpinfo it says it is using file
locks).
Is the warning above causing a problem or was
--enable-apc-pthreadmutex pulled out???
--- End Message ---
--- Begin Message ---
I take it back.. if I use --enable-apc-pthreadmutex I get file locks,
but if I don't use the option at all, I get pthreadmutexes. I'm
guessing pthead became the new default?
On Jan 7, 2008 1:59 PM, steve <[EMAIL PROTECTED]> wrote:
>
> When configuring APC 3.0.16 I see this, which I don't recall seeing before:
>
> checking dlfcn.h presence... no
> configure: WARNING: dlfcn.h: accepted by the compiler, rejected by the
> preprocessor!
> configure: WARNING: dlfcn.h: proceeding with the compiler's result
> checking for dlfcn.h... yes
>
> Also --enable-apc-pthreadmutex no longer seems to work (it is no
> longer in ./configure --help and in phpinfo it says it is using file
> locks).
>
> Is the warning above causing a problem or was
> --enable-apc-pthreadmutex pulled out???
>
--- End Message ---
--- Begin Message ---
Hi all,
I have a screen get_collection.php which is supposed to be used to
select something called 'data sets'. My database (the postgres database
is not the problem, PHP is) has an entity called 'data series' which has
a child entity called 'data sets'. The user is first shown a list of
all the data series. He selects a subset and pushes a submit button.
The database supplies the names of the children of the selected data
series, which are then displayed in the scrolling list called 'data sets'.
My problem is getting the various screens in my application to talk
to each other. I have another screen called edit_reference.php which
is used to edit a reference with an id re_reference_id. Midway through
this screen I want to link the reference of re_reference_id to data
series and data sets chosen by the user by following a link from
edit_reference.php to get_collection.php.
I thought I could just give re_reference_id to get_collection as an
url variable. Unfortunately, this doesn't work. Pushing the submit
button to actually select the data series of interest causes the $_GET
to be forgotten. Printing the value of re_reference_id in a hidden
inpput field -- which I thought for sure would end up in the $_POST
array when I hit the get_data_series submit button doesn't work either.
Neither does just saying $_POST['re_reference_id'] = $re_reference_id.
Probably I should be using session variables here. But I think they
will have their own problems since they will be written on
edit_reference.php, remembered long after the call to get_collections,
and may cause trouble later.
My page is
http://www.demog.berkeley.edu/~maryfran/memdev/get_collection.php?re_reference_id=74
I am going to attach the php code and hope it makes it through.
Mary Anderson
--- End Message ---
--- Begin Message ---
On Mon, January 7, 2008 7:20 pm, Mary Anderson wrote:
EVERY http request is totally separate and independent of any other
http request, unless YOU specifically code something in the URL or
SESSION to tie them together.
> I thought I could just give re_reference_id to get_collection as
> an
> url variable.
You could, but it would have to be part of the ACTION="..." URL in
order to get passed on to the next HTTP request.
> Unfortunately, this doesn't work. Pushing the submit
> button to actually select the data series of interest causes the $_GET
> to be forgotten. Printing the value of re_reference_id in a hidden
> inpput field -- which I thought for sure would end up in the $_POST
> array when I hit the get_data_series submit button doesn't work
> either.
This should have worked.
Review it and see what is in $_POST with:
<?php var_dump($_POST);?>
> Neither does just saying $_POST['re_reference_id'] = $re_reference_id.
You can do that in the first script, but it won't affect the next one.
And it's probably a Bad Idea to cram things into $_POST or other
built-ins, as a matter of style.
> Probably I should be using session variables here. But I think
> they
> will have their own problems since they will be written on
> edit_reference.php, remembered long after the call to get_collections,
> and may cause trouble later.
You would have to be sure that you give meaninful shelf-life and names
to the data you choose to put in $_SESSION, and not twist yourself
into knots by snarling up your own data...
But it works a treat if you plan that part out.
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/from/lynch
Yeah, I get a buck. So?
--- End Message ---
