php-general Digest 16 Aug 2008 14:08:00 -0000 Issue 5627
Topics (messages 278208 through 278226):
Re: SESSION problem
278208 by: VamVan
278216 by: tedd
278217 by: Stut
278218 by: Ashley Sheridan
278219 by: Sabine Richter
278220 by: tedd
278221 by: tedd
278222 by: Sabine Richter
278223 by: Stut
278224 by: tedd
278225 by: tedd
278226 by: Stut
Re: Conditional compilation
278209 by: Shawn McKenzie
278210 by: Robert Cummings
Re: Open Source Classifides
278211 by: Lupus Michaelis
Re: Buffering problem
278212 by: Anders Norrbring
Re: PHP editor for linux
278213 by: Richard Heyes
278214 by: Brice
Re: How to submit form via PHP
278215 by: pe.ve.ce.seznam.cz
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 ---
Tedd,
I think according to PHP manual. Session_start() must be the first line in
the code. Dont worry it will remember your session until you close the
browser and also it wont duplicate it.
Thanks
On Fri, Aug 15, 2008 at 4:39 PM, tedd <[EMAIL PROTECTED]> wrote:
> At 1:47 PM -0500 8/15/08, Boyd, Todd M. wrote:
>
>> Have you tried:
>>
>> echo SID;
>>
>> ...? I'm wondering if you're going to get different values on the two
>> pages. What that means beyond two different sessions is beyond me, but
>> it's a start.
>>
>>
>> Todd Boyd
>> Web Programmer
>>
>
> Todd:
>
> I added code to show the SID and it's the same, but still nothing happens.
>
> http://www.webbytedd.com/b2/session-test/index.php
>
> I know what the problem is, but don't know how to fix it.
>
> If you will look at the code, I am using a variable within the SESSION
> declaration:
>
> $_SESSION[$i] = $i;
>
> If I comment that out, the $_SESSION['test'] will be passed.
>
> Thanks,
>
> tedd
>
> --
> -------
> http://sperling.com http://ancientstones.com http://earthstones.com
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--- End Message ---
--- Begin Message ---
At 8:02 PM -0700 8/15/08, VamVan wrote:
Tedd,
I think according to PHP manual. Session_start() must be the first
line in the code. Dont worry it will remember your session until you
close the browser and also it wont duplicate it.
VamVan:
Yes, I thought that as well and practiced it for years, but that's
not true -- read the manual.
In any event, that's not the problem here.
The problem here is can I use a variable within a $_SESSION[] declaration?
Like so:
$_SESSION[$var]
Cheers,
tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com
--- End Message ---
--- Begin Message ---
On 16 Aug 2008, at 12:36, tedd wrote:
At 8:02 PM -0700 8/15/08, VamVan wrote:
Tedd,
I think according to PHP manual. Session_start() must be the first
line in the code. Dont worry it will remember your session until
you close the browser and also it wont duplicate it.
VamVan:
Yes, I thought that as well and practiced it for years, but that's
not true -- read the manual.
In any event, that's not the problem here.
The problem here is can I use a variable within a $_SESSION[]
declaration?
Like so:
$_SESSION[$var]
I haven't really been following this thread but using a variable like
that is perfectly valid. $_SESSION is no different to any other array
during the processing of your script, the only difference is that it's
stored between requests.
-Stut
--
http://stut.net/
--- End Message ---
--- Begin Message ---
session_start() doesn't have to be the first line in the code, but it
does have to occur before ANY content sent to the browser, and this
includes any headers as well. Generally speaking, it does no harm to
have it as the first line of your PHP code
Ash
www.ashleysheridan.co.uk
--- Begin Message ---
At 8:02 PM -0700 8/15/08, VamVan wrote:
Tedd,
I think according to PHP manual. Session_start() must be the first
line in the code. Dont worry it will remember your session until you
close the browser and also it wont duplicate it.
VamVan:
Yes, I thought that as well and practiced it for years, but that's
not true -- read the manual.
In any event, that's not the problem here.
The problem here is can I use a variable within a $_SESSION[] declaration?
Like so:
$_SESSION[$var]
Cheers,
tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--- End Message ---
--- End Message ---
--- Begin Message ---
Hello Tedd,
it seems to be a naming problem. You may not use a numeric value for a
variable name to store in $_SESSION.
By assigning it to $_SESSION, you get a
Notice: Unknown: Skipping numeric key 1 in Unknown on line 0
and in your second script a
Notice: Undefined offset: 1 in yourpath\index1.php on line XX ->
whatever line it was in your script
If you define
$_SESSION['var'.$i] = $i;
or $_SESSION[$i.'var'] = $i;
or even $_SESSION[$i.'.1'] = $i;
the $_SESSION won't forget your vars on the way to script 2.
But it's a bit strange, that you can use your numeric keys in script 1.
I tried with other Superglobals like $_POST and $_COOKIE and they seem
to accept numeric variable names.
So, is that a php bug?
But as the docu says "A valid variable name starts with a letter or
underscore", I think you can not complain about it.
Cheers
Sabine
tedd schrieb:
Hi gang:
Arrggg -- what the heck is going on?
I can't get anything to pass via SESSION -- what's wrong?
Here's the example -- (all the code is there):
I populate the $_SESSIONs here.
http://www.webbytedd.com/b2/session-test/index.php
If you click "Proceed to Step 2", you'll see that nothing is passed.
Now, where did I go wrong?
Cheers,
tedd
PS: I've tried this on two different servers and get the same results.
--- End Message ---
--- Begin Message ---
At 12:40 PM +0100 8/16/08, Stut wrote:
On 16 Aug 2008, at 12:36, tedd wrote:
The problem here is can I use a variable within a $_SESSION[] declaration?
Like so:
$_SESSION[$var]
I haven't really been following this thread but using a variable
like that is perfectly valid. $_SESSION is no different to any other
array during the processing of your script, the only difference is
that it's stored between requests.
-Stut
Stut:
I was hoping you would join in. But I solved the problem and found a
surprising result.
The result is you cannot use a number as an index in a $_SESSION, like so:
$a = "20";
$_SESSION[$a] = "good morning'; <-- won't work
But you can use:
$a = "a20';
$_SESSION[$a] = "good night'; <-- will work
Furthermore, if you do make that mistake, all other $_SESSION
variables declared AFTER the incident will cease to work. Isn't that
interesting?
Here's an example:
http://www.webbytedd.com/b2/session-test1/index.php
The code is at the bottom of the page.
Please tell me that you didn't know this, for if you do, it will make
my day. On the other hand, if you tell me where I it wrong, it will
still make my day. :-)
Always a pleasure listening to your thoughts and advice.
Cheers,
tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com
--- End Message ---
--- Begin Message ---
At 2:09 PM +0200 8/16/08, Sabine Richter wrote:
Hello Tedd,
it seems to be a naming problem. You may not use a numeric value for
a variable name to store in $_SESSION.
By assigning it to $_SESSION, you get a
Notice: Unknown: Skipping numeric key 1 in Unknown on line 0
and in your second script a
Notice: Undefined offset: 1 in yourpath\index1.php on line XX ->
whatever line it was in your script
If you define
$_SESSION['var'.$i] = $i;
or $_SESSION[$i.'var'] = $i;
or even $_SESSION[$i.'.1'] = $i;
the $_SESSION won't forget your vars on the way to script 2.
But it's a bit strange, that you can use your numeric keys in script 1.
I tried with other Superglobals like $_POST and $_COOKIE and they
seem to accept numeric variable names.
So, is that a php bug?
But as the docu says "A valid variable name starts with a letter or
underscore", I think you can not complain about it.
Cheers
Sabine
Sabine:
You hit the nail right on the head.
I discovered that fact this morning and posted an answer already.
Here's the demo:
http://www.webbytedd.com/b2/session-test1/index.php
I read everything I could find about sessions, but didn't come across:
"A valid variable name starts with a letter or underscore"
To the contrary, this is only what I found:
Variable names follow the same rules as other labels in PHP. A valid
variable name starts with a letter or underscore, followed by any
number of letters, numbers, or underscores
Where did you see that?
Cheers,
tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com
--- End Message ---
--- Begin Message ---
Hello Tedd,
tedd schrieb:
At 2:09 PM +0200 8/16/08, Sabine Richter wrote:
Hello Tedd,
it seems to be a naming problem. You may not use a numeric value for a
variable name to store in $_SESSION.
By assigning it to $_SESSION, you get a
Notice: Unknown: Skipping numeric key 1 in Unknown on line 0
and in your second script a
Notice: Undefined offset: 1 in yourpath\index1.php on line XX ->
whatever line it was in your script
If you define
$_SESSION['var'.$i] = $i;
or $_SESSION[$i.'var'] = $i;
or even $_SESSION[$i.'.1'] = $i;
the $_SESSION won't forget your vars on the way to script 2.
But it's a bit strange, that you can use your numeric keys in script 1.
I tried with other Superglobals like $_POST and $_COOKIE and they seem
to accept numeric variable names.
So, is that a php bug?
But as the docu says "A valid variable name starts with a letter or
underscore", I think you can not complain about it.
Cheers
Sabine
Sabine:
You hit the nail right on the head.
I discovered that fact this morning and posted an answer already. Here's
the demo:
http://www.webbytedd.com/b2/session-test1/index.php
Yes, our mails overlaped each other (Do you say that in english? My
english is not the best.)
I read everything I could find about sessions, but didn't come across:
"A valid variable name starts with a letter or underscore"
To the contrary, this is only what I found:
Variable names follow the same rules as other labels in PHP. A valid
variable name starts with a letter or underscore, followed by any number
of letters, numbers, or underscores
Where did you see that?
My citation is just a part of what you found.
By the way: I tried your initial code and I had no problem with the
variable declared after the numeric ones. (your $_SESSION['test']). I
tried on a Version 5.2.5 an Win XP.
Cheers,
Sabine
Cheers,
tedd
--- End Message ---
--- Begin Message ---
On 16 Aug 2008, at 13:20, tedd wrote:
At 12:40 PM +0100 8/16/08, Stut wrote:
On 16 Aug 2008, at 12:36, tedd wrote:
The problem here is can I use a variable within a $_SESSION[]
declaration?
Like so:
$_SESSION[$var]
I haven't really been following this thread but using a variable
like that is perfectly valid. $_SESSION is no different to any
other array during the processing of your script, the only
difference is that it's stored between requests.
-Stut
Stut:
I was hoping you would join in. But I solved the problem and found a
surprising result.
The result is you cannot use a number as an index in a $_SESSION,
like so:
$a = "20";
$_SESSION[$a] = "good morning'; <-- won't work
But you can use:
$a = "a20';
$_SESSION[$a] = "good night'; <-- will work
Furthermore, if you do make that mistake, all other $_SESSION
variables declared AFTER the incident will cease to work. Isn't that
interesting?
Here's an example:
http://www.webbytedd.com/b2/session-test1/index.php
The code is at the bottom of the page.
Please tell me that you didn't know this, for if you do, it will
make my day. On the other hand, if you tell me where I it wrong, it
will still make my day. :-)
Ahh, I see the problem. You've never been able to use numbers as keys
at the root level of the $_SESSION array. It's not a bug, it's just
the way it is. I've just checked the documentation and can't find an
obvious reference to this limitation which is kinda annoying.
I would question why you would want to do such a thing. Whenever I use
sessions (which is rare these days) I tend to organise the data with
some sort of context, which generally doesn't end up using pure numbers.
If you really want to use numeric indices in your session array you
can do so by adding a second level, i.e. $_SESSION['vars'] = array(20
=> 'good night');
-Stut
--
http://stut.net/
--- End Message ---
--- Begin Message ---
At 2:11 PM +0100 8/16/08, Stut wrote:
Ahh, I see the problem. You've never been able to use numbers as
keys at the root level of the $_SESSION array. It's not a bug, it's
just the way it is. I've just checked the documentation and can't
find an obvious reference to this limitation which is kinda annoying.
I agree.
But what I find even more annoying is:
1) No error is generated.
2) The error prohibits ALL other SESSION variables legally declared
after the error to stop working!
In other words, if you make the mistake of using a numeric index for
a SESSION, then ALL legal SESSIONs declared after that will stop
working. And, what makes this even more frustrating is that ALL
SESSIONs declared before will continue to work. IMO, it would be
better if once you screwed it up, then everything would stop working.
So, let's say this happens (as it did to me last year), you have a
set of scripts that work fine and in one script you use a numeric
index for a SESSION. Once that statement is encountered in the flow
of the program, ALL other SESSION variables declared after that don't
work anymore.
In one sequence of scripts everything worked fine and in a different
sequence only some things work. That was maddening and I never knew
what it was until now. And, no mention of this problem in the
documentation.
This should give you a bit more ammunition for your "I never use
SESSIONs for anything" argument.
--- you further stated
I would question why you would want to do such a thing.
You have never moved data between arrays?!? Come on, I'm sure you
have done it before.
It's an old habit I have filling arrays -- I never had any problems
using numbers before.
This works:
for ($i; $i<10; $i++)
{
$things[$i] = $other_things[$i];
}
I was looking at SESSION the same way -- after all it IS called an array.
Let me play the age-card -- in every language I've programmed in for
the last 43 years an array can have numeric indexes -- except php's
SESSION.
Thanks for your comments.
Cheers,
tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com
--- End Message ---
--- Begin Message ---
At 2:45 PM +0200 8/16/08, Sabine Richter wrote:
Yes, our mails overlaped each other (Do you say that in english? My
english is not the best.)
Sabine:
Your English is fine -- much better than my de for certain.
By the way: I tried your initial code and I had no problem with the
variable declared after the numeric ones. (your $_SESSION['test']).
I tried on a Version 5.2.5 an Win XP.
That's interesting.
Let's make sure we're talking about the same thing here.
This is the demo:
http://www.webbytedd.com/b2/session-test1/index.php
In my browser Step 1 shows:
SESSION[20] => good morning
SESSION[test2] => good night
In Step 2:
Neither are there.
Is that what you see?
Cheers,
tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com
--- End Message ---
--- Begin Message ---
On 16 Aug 2008, at 14:46, tedd wrote:
At 2:11 PM +0100 8/16/08, Stut wrote:
Ahh, I see the problem. You've never been able to use numbers as
keys at the root level of the $_SESSION array. It's not a bug, it's
just the way it is. I've just checked the documentation and can't
find an obvious reference to this limitation which is kinda annoying.
I agree.
But what I find even more annoying is:
1) No error is generated.
2) The error prohibits ALL other SESSION variables legally declared
after the error to stop working!
In other words, if you make the mistake of using a numeric index for
a SESSION, then ALL legal SESSIONs declared after that will stop
working. And, what makes this even more frustrating is that ALL
SESSIONs declared before will continue to work. IMO, it would be
better if once you screwed it up, then everything would stop working.
So, let's say this happens (as it did to me last year), you have a
set of scripts that work fine and in one script you use a numeric
index for a SESSION. Once that statement is encountered in the flow
of the program, ALL other SESSION variables declared after that
don't work anymore.
In one sequence of scripts everything worked fine and in a different
sequence only some things work. That was maddening and I never knew
what it was until now. And, no mention of this problem in the
documentation.
This should give you a bit more ammunition for your "I never use
SESSIONs for anything" argument.
Not really, since I would never name a session variable 1, or 2, or
5318008 - I would always put those in the session in a named array.
--- you further stated
I would question why you would want to do such a thing.
You have never moved data between arrays?!? Come on, I'm sure you
have done it before.
It's an old habit I have filling arrays -- I never had any problems
using numbers before.
This works:
for ($i; $i<10; $i++)
{
$things[$i] = $other_things[$i];
}
I was looking at SESSION the same way -- after all it IS called an
array.
Let me play the age-card -- in every language I've programmed in for
the last 43 years an array can have numeric indexes -- except php's
SESSION.
I wish I understood the reason why it's like this but I've never
looked into the session extension in that level of detail, but I doubt
such a limitation would exist if there was not a very good reason for
it. But again, I don't see how this is relevant.
It's natural to me to see the session array as a filing cabinet. At
the top level you would have files with names that indicate what they
are. Within each file it may be further divided into numbered
sections. Given that I can't see into the future, even if I currently
only have one set of data (file) to store in the session (the filing
cabinet) I wouldn't just chuck the bits of paper from the file into
the filing cabinet. I'd leave them in the file such that when I need
to add a new file I don't need to gather up all the other bit of paper
into a single file to get it organised again.
Ok, that didn't quite make it as clear as I wanted it to but I hope it
illustrates the point I'm trying to make. The root level of the
session array (IMHO) should contain descriptive keys, and I've never
been in a situation where 5318008 is descriptive and gives context to
the data unless you turn it upside down!
-Stut
--
http://stut.net/
--- End Message ---
--- Begin Message ---
Robert Cummings wrote:
On Fri, 2008-08-15 at 18:34 -0500, Shawn McKenzie wrote:
Herman Gomez wrote:
Hi,
Here is something I used to do in C/C++ to include/exclude automaticaly
all debugging code at compiling time:
#define debug TRUE
#ifdef(debug)
//debugging code
#endif
That way I can include/exclude easily all debugging code in the final
compiled code. In PHP I have not been able to find anything like that.
The only solution I've found is having this kind of code in every debug
code block:
if ($debug) {
//debugging code
}
But this means that the debugging code is in the final compiled
(interpreted) code, wasting cpu cycles even if there won't be any
debugging in production.
Does somebody know if there is something like conditional compilation in
PHP that I can use?
Regards,
Herman Gomez
Madrid, Spain.
Well PHP isn't compiled it's interpreted. Still I don't see much diff
and no overhead between the following:
#ifdef(debug)
//debugging code
#endif
---and---
if (defined('DEBUG')) {
//debugging code
}
I don't think checking a define is cpu intensive or even measurable.
You could "assume" that it's defined as true or false and:
if (DEBUG === true)) {
//debugging code
}
Still, I don't think that even checking $debug is measurable.
That depends on where the conditional exists. In C you can place it
anywhere, including wihtin a tight loop. In PHP you end up having to
either take an overhead penalty or duplicate code to force the
conditional outside of a tight loop.
Contrast the following:
<?php
if( DEBUG === true )
{
for( $i = 0; $i < 1000000; $i++ )
{
// Do something common between DEBUG and !DEBUG modes.
// Do something dependent on debug mode.
}
}
else
{
for( $i = 0; $i < 1000000; $i++ )
{
// Do something common between DEBUG and !DEBUG modes.
}
}
?>
Versus:
<?php
for( $i = 0; $i < 1000000; $i++ )
{
// Do something common between DEBUG and !DEBUG modes.
if( DEBUG === true )
{
// Do something dependent on debug mode.
}
}
?>
Now depending on what "Do something common between DEBUG and !DEBUG
modes" does, it can be a real PITA to do code duplication to optimize
debug mode handling, but on the other hand, you really don't want to
check if DEBUG is enabled 1 million times.
If I recall though... a few years ago the answer to this question was
that there's no reason why you can't use the C pre-processor to
accomplish the same thing with PHP. The down side though is that then
you lose debugging information such as the real line number on which an
error occurs.
Cheers,
Rob.
Great! Then the answer is: wait, wait,
write it in C!
-Shawn
--- End Message ---
--- Begin Message ---
On Fri, 2008-08-15 at 22:56 -0500, Shawn McKenzie wrote:
> Robert Cummings wrote:
> > On Fri, 2008-08-15 at 18:34 -0500, Shawn McKenzie wrote:
> >> Herman Gomez wrote:
> >>> Hi,
> >>>
> >>> Here is something I used to do in C/C++ to include/exclude automaticaly
> >>> all debugging code at compiling time:
> >>>
> >>> #define debug TRUE
> >>> #ifdef(debug)
> >>> //debugging code
> >>> #endif
> >>>
> >>> That way I can include/exclude easily all debugging code in the final
> >>> compiled code. In PHP I have not been able to find anything like that.
> >>> The only solution I've found is having this kind of code in every debug
> >>> code block:
> >>>
> >>> if ($debug) {
> >>> //debugging code
> >>> }
> >>>
> >>> But this means that the debugging code is in the final compiled
> >>> (interpreted) code, wasting cpu cycles even if there won't be any
> >>> debugging in production.
> >>>
> >>> Does somebody know if there is something like conditional compilation in
> >>> PHP that I can use?
> >>>
> >>> Regards,
> >>> Herman Gomez
> >>> Madrid, Spain.
> >> Well PHP isn't compiled it's interpreted. Still I don't see much diff
> >> and no overhead between the following:
> >>
> >> #ifdef(debug)
> >> //debugging code
> >> #endif
> >>
> >> ---and---
> >>
> >> if (defined('DEBUG')) {
> >> //debugging code
> >> }
> >>
> >> I don't think checking a define is cpu intensive or even measurable.
> >> You could "assume" that it's defined as true or false and:
> >>
> >> if (DEBUG === true)) {
> >> //debugging code
> >> }
> >>
> >> Still, I don't think that even checking $debug is measurable.
> >
> > That depends on where the conditional exists. In C you can place it
> > anywhere, including wihtin a tight loop. In PHP you end up having to
> > either take an overhead penalty or duplicate code to force the
> > conditional outside of a tight loop.
> >
> > Contrast the following:
> >
> > <?php
> >
> > if( DEBUG === true )
> > {
> > for( $i = 0; $i < 1000000; $i++ )
> > {
> > // Do something common between DEBUG and !DEBUG modes.
> > // Do something dependent on debug mode.
> > }
> > }
> > else
> > {
> > for( $i = 0; $i < 1000000; $i++ )
> > {
> > // Do something common between DEBUG and !DEBUG modes.
> > }
> > }
> >
> > ?>
> >
> > Versus:
> >
> > <?php
> >
> > for( $i = 0; $i < 1000000; $i++ )
> > {
> > // Do something common between DEBUG and !DEBUG modes.
> >
> > if( DEBUG === true )
> > {
> > // Do something dependent on debug mode.
> > }
> > }
> >
> > ?>
> >
> > Now depending on what "Do something common between DEBUG and !DEBUG
> > modes" does, it can be a real PITA to do code duplication to optimize
> > debug mode handling, but on the other hand, you really don't want to
> > check if DEBUG is enabled 1 million times.
> >
> > If I recall though... a few years ago the answer to this question was
> > that there's no reason why you can't use the C pre-processor to
> > accomplish the same thing with PHP. The down side though is that then
> > you lose debugging information such as the real line number on which an
> > error occurs.
> >
> > Cheers,
> > Rob.
>
> Great! Then the answer is: wait, wait,
>
> write it in C!
Well PHP does have a great extension system so you can plug in your own
C code ;)
Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP
--- End Message ---
--- Begin Message ---
Joey a écrit :
Does anyone know of a good php based classified system?
What do you mean by classified system ?
--
Mickaël Wolff aka Lupus Michaelis
http://lupusmic.org
--- End Message ---
--- Begin Message ---
> Anders Norrbring a écrit :
> > I'm running out of ideas to where to look for this, so can you please
> give
> > me some pointers?
>
> I guess it is that you're seeking for :
> <http://fr.php.net/manual/en/outcontrol.configuration.php#ini.implicit-
> flush>
Thank you!
Worked just as I want..
Anders
--- End Message ---
--- Begin Message ---
>> > > > pico :-)
>> > >
>> > > ed baby; its all about ed!
>> >
>> > hexedit /dev/sda1
I do seriously use pico. My editing needs on Linux are small, via a
puTTY window and pico is the most like a Windows editor that I've used
(compared to vi say with its command/edit modes). I've used it for
years, am very comfortable with it (you might say blinkered to it...),
and do not see a need to make a switch to something more powerful or
versatile.
--
Richard Heyes
http://www.phpguru.org
--- End Message ---
--- Begin Message ---
On Fri, Aug 15, 2008 at 5:11 PM, Shawn McKenzie <[EMAIL PROTECTED]>wrote:
> It flance wrote:
>
>> Hi,
>>
>> What do you think is the best php editor for linux.
>>
>> I'm using the Debian distribution.
>>
>> Thanks
>>
>>
>>
>>
>
> I use Aptana which is based on eclipse and has built-in HTML/JS/PHP?SVN
> stuff. Also a cool plugin that lets you easily develop for the iPhone and
> preview it.
>
Aptana is very good. I use it in addition to Eclipse PDT. Aptana brings
html, css and ftp features.
Brice
> -Shawn
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--- End Message ---
--- Begin Message ---
Many thanks, Todd, and others.
Matěj "czech_d3vl0p3r" Grabovský
> ------------ Původní zpráva ------------
> Od: Boyd, Todd M. <[EMAIL PROTECTED]>
> Předmět: RE: [PHP] How to submit form via PHP
> Datum: 15.8.2008 22:43:40
> ----------------------------------------
> > -----Original Message-----
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> > Sent: Friday, August 15, 2008 2:54 PM
> > To: [EMAIL PROTECTED]
> > Subject: RE: [PHP] How to submit form via PHP
> >
> > Thanks, that was what I needed. Also I found this:
> > http://curl.haxx.se/libcurl/php/examples/./simplepost.html. Is it
> > somehow possible to retrieve result of that operation?
> >
> > Thanks in advance.
> >
> > Matěj "czech_d3v3l0pr" Grabovský
>
> I believe:
>
> curl_setopt(CURLOPT_RETURNTRANSFER, true);
> $result = curl_exec($ch);
>
> ...will send the output from cURL to the variable rather than the web
> browser/screen.
>
>
> Todd Boyd
> Web Programmer
>
>
>
>
>
>
--- End Message ---