php-general Digest 16 Aug 2008 14:08:00 -0000 Issue 5627

Sat, 16 Aug 2008 07:10:43 -0700 

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 ---

Reply via email to