Slashdot Mirror

Any decent language has full PCRE support these days. Perls days as regular expression king are in the past. Sure it may have set the standard for how it's done, but now it's no longer a selling point. Plenty of other nicer languages exist.

I can vouch that, to the extent that I've been trying it, all of my PHP4-developed code has been working fine with the PHP5 interpreter so far. As andig suggests above, I suspect that only a few cases where someone relies heavily on 4.x "quirks" will cause a problem.

I was slightly disappointed to find that the "native Java/PHP integration" support was quietly dropped from PHP5 - I'd been wanting to play with that. Oh well.

Yes the official interpreter is cross-platform, it is available for *nix and Windows.

Check out the downloads section at php.net for Windows binaries and *nix source, and here you can find more details on PHP under Mac OS X.

As for the compiler in the story, I haven't tried it before so I don't know.

Of course these errors shouldn't be visible to the user. However, it's up to you the developer to change the error output. PHP supports numerous different error reporting methods. Don't blame PHP for 'problems' that arise because you don't bother changing a default setting or two.

PHP error handling and logging

My main issue with PHP scalability is the lack of a global context for app-level caching.

http://www.php.net/manual/en/ref.sem.php -- system V shared memory. See specifically the functions shm_put_var() and shm_get_var().

I don't see any part of the article addressing how PHP can benefit the developer facing real issues of large scale web development (such as the need for caching systems on high volume websites, or the maintence challenge of larger code bases on complex sites).

The article doesn't mention it, but Smarty is an excellent PHP library that implements, among other things, caching. I have used it extensively with excellent results.

Yes, you can. This is a huge misconception about Windows. I SSH into my work computer regularly (I'm in IT support). It has an SSH server installed. Through this, from home, I can double-click an icon on my desktop, enter a password, and it'll restart our apache servers. It's not difficult to do at all.

Scripting in windows is another great feat. Windows has a scripting host built in, which offers incredible functionality. It can use COM objects, which essentially allow your scripts to interface with most software you install on your computer (from Office, IE, iTunes, whatever), all within a script. PHP also runs on Windows, and that lets you write scripts. I've been using linux for years, and Windows for longer, and I have no problem getting Windows to do exactly what I want. Linux is definitely no more adaptable.

PHP+Apache2 is "working OK"...

Just not well enough to sign off an enterprise solution on...

Check out these links for more details...
PHP-Dev Mailing list discussion
Discussion on PHP buglist
as well as a more tongue-in-cheek reply...

PHP+Apache2 is "working OK"...

Just not well enough to sign off an enterprise solution on...

Check out these links for more details...
PHP-Dev Mailing list discussion
Discussion on PHP buglist
as well as a more tongue-in-cheek reply...

PHP developers are not opposed to Apache 2.x.

Certainly, noone is opposed to Apache 2.x. It is a very good idea to make PHP work flawlessly with Apache 2, and once some certain technical problems gets corrected everything will be nice.

PHP is stable on Apache 1.3 _AND_ 2.x.

PHP is not stable with Apache 2. Rasmus Lerdorf's explanation is widely known, and is part of PHP's FAQ now. Basically, many extensions that PHP rely upon don't work well in threaded environments, and it's quite tricky to know exactly which ones and how to fix them (either on the library level or the PHP level).

Apache 2.x has a large number of new features designed to better handle high volume sites (with or without PHP)

Apache 2 was built to handle high volume sites differently, which happens to provide a huge performance boost on Win32 systems.

All in all, your message is kind of disappointing for someone who sounds like he knows what he's talking about.

If you understand SQL, PostgreSQL is easy and you shouldn't need explanation on how to run queries from PHP.

You ought to be using PEAR's DB class anyway, which abstracts away most of the differences in dialect.

and don't forget sockets!
i wrote an encrypted chat client/server combo using php exclusively with ncurses and sockets
source is here

it's a bit hard to setup, because it was just a for phun project... man php is great

Um, all you need to know about using the CLI is on this page:

http://us4.php.net/features.commandline

As for php-gtk, there are much better alternatives. And I don't exactly have much faith in something that's developed and supported by only one developer (the cantankerous Andrei Zmievski no less).

Part V, Extensibility, is for people who want to adapt PHP on the language level for their needs

This is an often-overlooked advantage in PHP: the ability to use php-embed to run embedded PHP within another application. For example, our company has created an HL7 HIPAA-accelerator in C/C++; we chose PHP as the embedded language in our product--by which users can create custom data transformations.

The reason? PHP is easy to use, loosely-typed (which is an advantage in our project), fast, and of course, free. It was a great decision.

Would it be that much of a intellectual hurdle to switch to Perl, where you can leverage CPAN?

To accompany the addition of the CLI interface to PHP in 4.3.x, the PEAR repository was created. It is very much CPAN-like with a couple hundred maturing PHP OOP modules. Noteworthy among them is a DB module that provides database abstraction. Installing modules is as easy as

pear install MODULE

Currently you aren't seeing PEAR used much because of its late addition to the 4.x series, but as soon as web hosts move to and embrace PHP 5 there should be a pretty good growth period. The same is true with the CLI interface, but it is taking hold. The m0n0wall FreeBSD router/firewall/packet shaper project uses PHP for system configuration instead of traditional bash shell scripts and C programs.

Would it be that much of a intellectual hurdle to switch to Perl, where you can leverage CPAN?

To accompany the addition of the CLI interface to PHP in 4.3.x, the PEAR repository was created. It is very much CPAN-like with a couple hundred maturing PHP OOP modules. Noteworthy among them is a DB module that provides database abstraction. Installing modules is as easy as

pear install MODULE

Currently you aren't seeing PEAR used much because of its late addition to the 4.x series, but as soon as web hosts move to and embrace PHP 5 there should be a pretty good growth period. The same is true with the CLI interface, but it is taking hold. The m0n0wall FreeBSD router/firewall/packet shaper project uses PHP for system configuration instead of traditional bash shell scripts and C programs.

Would it be that much of a intellectual hurdle to switch to Perl, where you can leverage CPAN?

To accompany the addition of the CLI interface to PHP in 4.3.x, the PEAR repository was created. It is very much CPAN-like with a couple hundred maturing PHP OOP modules. Noteworthy among them is a DB module that provides database abstraction. Installing modules is as easy as

pear install MODULE

Currently you aren't seeing PEAR used much because of its late addition to the 4.x series, but as soon as web hosts move to and embrace PHP 5 there should be a pretty good growth period. The same is true with the CLI interface, but it is taking hold. The m0n0wall FreeBSD router/firewall/packet shaper project uses PHP for system configuration instead of traditional bash shell scripts and C programs.

I used to think that too but I have changed my mind. If there was nothing magical about perl then all languages would have a centralized library of objects and a easy way to download and install them (including dependency resolving). I agree with you that all languages should have this none of them do and there must be a reason for it.

PHP has PEAR. Examples:

pear list
pear install MODULE
pear upgrade MODULE
pear upgrade-all

A prime example is the way that Perl has seperate numrical and string comparitors (==/!= and eq/ne) whereas PHP has only the one (==). This recently came up in the story about the Perl periodic table of elements and I even gave my own answer on this problem. Just to rehash: Perl and PHP are loosely-typed languages so the programmer really needs to tell the interpreter how to compare the mixed numerical/string "scalar" type that both Perl and PHP use. But PHP tries to simplify at the expense of introducing ambiguity.

PHP has == and != for simple comparison, and === and !== for enforcing that the comparants (is that a word?) are also of the same type.

See http://nl3.php.net/manual/en/language.operators.co mparison.php.

JP

PHP succeeds an older product, named PHP/FI. PHP/FI was created by Rasmus Lerdorf in 1995, initially as a simple set of Perl scripts for tracking accesses to his online resume. He named this set of scripts 'Personal Home Page Tools'. As more functionality was required, Rasmus wrote a much larger C implementation, which was able to communicate with databases, and enabled users to develop simple dynamic Web applications. Rasmus chose to release the source code for PHP/FI for everybody to see, so that anybody can use it, as well as fix bugs in it and improve the code.

PHP/FI, which stood for Personal Home Page / Forms Interpreter, included some of the basic functionality of PHP as we know it today. It had Perl-like variables, automatic interpretation of form variables and HTML embedded syntax. The syntax itself was similar to that of Perl, albeit much more limited, simple, and somewhat inconsistent.

Every job has its requirements; being a good programmer is being able to use the tools you have to solve the problem in a way that fits the requirements. Being a great programmer is knowing which tool is right for the job - and which isn't - and when they may have to look for something else.

Please, please, please read the the code (or at least the announcement) before replying. You are totally off the mark here. In short: It's easy to create a webserver in PHP (everybody did it so I did too: http://ter.dk:4281/ ), but we are talking about a TCP/IP-stack as well.

And please, please, please don't mark any post "Informative", just because it is shorter than the original announcement.

In response to a lot of other bewildered posts:

• Yes, PHP is able to run standalone, and has "always" been so. Just compile the CGI executable. Furthermore, it is now split up in a CGI- and CLI-version. Hint: Using PHP from the command line
• Yes, PHP is able to create TCP-connections and UDP-"connections" (in reality meaning just sending a package and retrieve a possible answer), and has been so for a long time (it was present yet unstable in PHP/FI, but worked fine from PHP3 - UDP-support was added later on). Hint: fsockopen()
• Yes, PHP is able to listen to a port and has been so since PHP4.1.0. Hint: socket_create_listen()
• Yes, PHP with process control enabled is able to fork and spawn childs, also since PHP4.1.0. Hint: pcntl_fork()

Okay, get ready for the explanation of the announcement: PHP is just relying on the underneath TCP/IP-stack. Adams example includes the TCP/IP-stack itself (including ICMP). That's pretty neat.

Please, please, please read the the code (or at least the announcement) before replying. You are totally off the mark here. In short: It's easy to create a webserver in PHP (everybody did it so I did too: http://ter.dk:4281/ ), but we are talking about a TCP/IP-stack as well.

And please, please, please don't mark any post "Informative", just because it is shorter than the original announcement.

In response to a lot of other bewildered posts:

• Yes, PHP is able to run standalone, and has "always" been so. Just compile the CGI executable. Furthermore, it is now split up in a CGI- and CLI-version. Hint: Using PHP from the command line
• Yes, PHP is able to create TCP-connections and UDP-"connections" (in reality meaning just sending a package and retrieve a possible answer), and has been so for a long time (it was present yet unstable in PHP/FI, but worked fine from PHP3 - UDP-support was added later on). Hint: fsockopen()
• Yes, PHP is able to listen to a port and has been so since PHP4.1.0. Hint: socket_create_listen()
• Yes, PHP with process control enabled is able to fork and spawn childs, also since PHP4.1.0. Hint: pcntl_fork()

Okay, get ready for the explanation of the announcement: PHP is just relying on the underneath TCP/IP-stack. Adams example includes the TCP/IP-stack itself (including ICMP). That's pretty neat.

Please, please, please read the the code (or at least the announcement) before replying. You are totally off the mark here. In short: It's easy to create a webserver in PHP (everybody did it so I did too: http://ter.dk:4281/ ), but we are talking about a TCP/IP-stack as well.

And please, please, please don't mark any post "Informative", just because it is shorter than the original announcement.

In response to a lot of other bewildered posts:

• Yes, PHP is able to run standalone, and has "always" been so. Just compile the CGI executable. Furthermore, it is now split up in a CGI- and CLI-version. Hint: Using PHP from the command line
• Yes, PHP is able to create TCP-connections and UDP-"connections" (in reality meaning just sending a package and retrieve a possible answer), and has been so for a long time (it was present yet unstable in PHP/FI, but worked fine from PHP3 - UDP-support was added later on). Hint: fsockopen()
• Yes, PHP is able to listen to a port and has been so since PHP4.1.0. Hint: socket_create_listen()
• Yes, PHP with process control enabled is able to fork and spawn childs, also since PHP4.1.0. Hint: pcntl_fork()

Okay, get ready for the explanation of the announcement: PHP is just relying on the underneath TCP/IP-stack. Adams example includes the TCP/IP-stack itself (including ICMP). That's pretty neat.

Please, please, please read the the code (or at least the announcement) before replying. You are totally off the mark here. In short: It's easy to create a webserver in PHP (everybody did it so I did too: http://ter.dk:4281/ ), but we are talking about a TCP/IP-stack as well.

And please, please, please don't mark any post "Informative", just because it is shorter than the original announcement.

In response to a lot of other bewildered posts:

• Yes, PHP is able to run standalone, and has "always" been so. Just compile the CGI executable. Furthermore, it is now split up in a CGI- and CLI-version. Hint: Using PHP from the command line
• Yes, PHP is able to create TCP-connections and UDP-"connections" (in reality meaning just sending a package and retrieve a possible answer), and has been so for a long time (it was present yet unstable in PHP/FI, but worked fine from PHP3 - UDP-support was added later on). Hint: fsockopen()
• Yes, PHP is able to listen to a port and has been so since PHP4.1.0. Hint: socket_create_listen()
• Yes, PHP with process control enabled is able to fork and spawn childs, also since PHP4.1.0. Hint: pcntl_fork()

Okay, get ready for the explanation of the announcement: PHP is just relying on the underneath TCP/IP-stack. Adams example includes the TCP/IP-stack itself (including ICMP). That's pretty neat.

The community has been extremely helpful and the online documentation is awsome.

Yeah. Like the extremely useful documentation of the DOMXML functions. I mean, XML is so strange no one will ever use it anyway, right? The expat-based XML functions are even worse - there is at least some info, but the examples completely fail to show WTF one is supposed to do with those. Google knew the answers, but a good documentation should make googling mostly obsolete.

Could somebody who knows WTF they are doing tell me if it's possible without using an applet to get this to open a socket back?

Could somebody who knows WTF they are doing tell me if it's possible without using an applet to get this to open a socket back?

A while back I was looking at PHP's COM support...
Technically, shouldn't it be possible to use DirectX with PHP as well, using this COM functionality?

This is a very cool thing heh.. but it isn't to be unexpected, as phpopengl was already made, but this new one looks great as well. But who knows what other things will come out... Look at all of these things that php can do here ,there are a bunch of interesting and very useful mods, and more come out all the time. Also, take a look at that link, it gives you a good idea of what php can do (although there is much more than what is on that page).

At least it let me know about the useful ffi extension. If it wasn't for this cute demo, I'd have never come across this.

...Is truly a lost art.

Of course, we already knew this.

Although the official reason that GnomeBasic was dropped was because of "stagnation", the real reason that it died was because Mono was supposed to take it's place.

If that happened, I've seen no evidence of it.

While you can write Mono code in Java, PHP, Logo, Oberon, Pascal, Forth and Lisp, VB is still unavailable.

It's a pity such a popular language appears to be entirely ignored.

The problem with learning to program is that unless you can forsee a possible use for it, it's hard to be motivated to follow through with the studies. Your Mom may want to learn programming in the abstract, but the challenge is enough to keep her from following through since she doesn't really know what she'd do with the skills once she's got them.

HTML is the perfect answer to the problem. With even basic HTML she can do something productive. Help her come up with an idea for a web site (Geneaology, recipes, particle physics, whatever interests her...) & put her to work.

Once she has basic HTML, Skip Javascript & go straight to PHP. By the time she's here, she'll probably have some ideas on what she can do with the language, so she'll be more motivated to tackle the (fairly shallow) learning curve.

As far as more traditional programming, I highly recommend Ruby (though the site is down temporarily). It has all the power of a language like Perl or Python, but it's syntax is quite clean and simple, and close enough to natural english that the code quite readable even if you don't know the language. For anyone new to programming who wants to write things that are in the realm of a scripting language, I wholeheartedly recommend it.

the w3schoole table is rather incomplete -
consider using php.net operators manual instead - there are more of them (but far away from maxing out ascii like perl 6 is about to do)

Give me a break ... where do the disclaimers stop? I mean, the software's being given away for free for non-commercial use, and I think it's of interest to other techies. Notice I didn't submit anonymously.

And don't start spouting "open-source this, open-source that" to me ... I do my bit there as well. But noone cares about that stuff, so why bother talking about it instead of stuff I think is fun?

so you don't have to remember how to execute SQL on a MySQL database, Postgresql, Oracle, etc., like in PHP -- because in languages like PHP they all use different functions.

Um, do you have something against the Pear DB package and putting "require_once 'DB.php';" in your PHP code?

APD. It's been around for several years (it was hosted elsewhere before being moved to PECL in 2002).

PHP has a debugger build in. Check out this php website

I should think libexif should work just as well under PHP. Cf. the 07-Feb-2004 comment.

fopen() can open local files & URLs - look at the http:// example:
fopen()

fgets() will read in data from the steam - you can pick how many bytes you want to read in:
fgets()

Dont forget to use fclose() afterwards!

When you get those functions working, it's just a matter of interpreting the content returned. PHP has many useful string functions - many more than ASP does.

These functions are analogous to using a Microsoft.XMLHTTP object:
myXMLHTTPObject.Open "GET", someURL

The PHP and ASP way are both neat ways to read content from [X]HTML pages on other servers (the weather, share prices, etc) - although it might not be 100% ethical!

Hope this helps... I have nothing better to do while I wait for Fedora Core 2 to be delivered. Oh wait, I do... I'm at work reading Slashdot!

fopen() can open local files & URLs - look at the http:// example:
fopen()

fgets() will read in data from the steam - you can pick how many bytes you want to read in:
fgets()

Dont forget to use fclose() afterwards!

When you get those functions working, it's just a matter of interpreting the content returned. PHP has many useful string functions - many more than ASP does.

These functions are analogous to using a Microsoft.XMLHTTP object:
myXMLHTTPObject.Open "GET", someURL

The PHP and ASP way are both neat ways to read content from [X]HTML pages on other servers (the weather, share prices, etc) - although it might not be 100% ethical!

Hope this helps... I have nothing better to do while I wait for Fedora Core 2 to be delivered. Oh wait, I do... I'm at work reading Slashdot!

http://us2.php.net/manual/en/security.variables.ph p

Here's the intro:

"User Submitted Data

The greatest weakness in many PHP programs is not inherent in the language itself, but merely an issue of code not being written with security in mind. For this reason, you should always take the time to consider the implications of a given piece of code, to ascertain the possible damage if an unexpected variable is submitted to it."

There are lots of PHP scripts that require register_globals on, as until relatively recently that was the default setting.

Well, it was strongly mentioned as a security issue on 10-Dec-2001 when version 4.1.0 was announced:

http://www.php.net/release_4_1_0.php

And it was turned off as a default with the 4.2.0 release on 22-Apr-2002 - two years ago.

http://www.php.net/ChangeLog-4.php#4.2.0

Version 4.2.0

* ATTENTION!! register_globals defaults to 'off' now !!!

Considering that php 4 was released in May 2000, that's half of it's current lifetime. That's when I stopped using register_global variables, and started writing code properly, instead of giving a bad name to php. It's not a terribly difficult thing to clean up either... it's just that most php authors these days are too lazy to deal with it.

There are lots of PHP scripts that require register_globals on, as until relatively recently that was the default setting.

Well, it was strongly mentioned as a security issue on 10-Dec-2001 when version 4.1.0 was announced:

http://www.php.net/release_4_1_0.php

And it was turned off as a default with the 4.2.0 release on 22-Apr-2002 - two years ago.

http://www.php.net/ChangeLog-4.php#4.2.0

Version 4.2.0

* ATTENTION!! register_globals defaults to 'off' now !!!

Considering that php 4 was released in May 2000, that's half of it's current lifetime. That's when I stopped using register_global variables, and started writing code properly, instead of giving a bad name to php. It's not a terribly difficult thing to clean up either... it's just that most php authors these days are too lazy to deal with it.

After tearing my hair out for eight hours, I finally figured out how to untar a file (yes, I know about fopen and sockets). You need to specify /bin/sh -c "command". For example: ...

The super-global variables were first available in php4.0 beta 4 (released 2/2000), and were upgraded in 4.1 (12/2001), for further information, see PHP's ChangeLog.

The biggest change this created was discouraging people from using register_globals - probably the biggest security hazard until that time with writing php. This has been turned off by default since then, but unfortunately I'm still seeing developers rely upon this awful feature.

This doesn't make php bad, it makes those who write with that feature bad programmmers. Just because you can plow over a pedestrian with your car, it doesn't mean that everyone should have their car taken away... it just means that they're crappy drivers.

When a file is included, parsing drops out of PHP mode and into HTML mode at the beginning of the target file, and resumes again at the end. For this reason, any code inside the target file which should be executed as PHP code must be enclosed within valid PHP start and end tags. [emphasis mine]

<IMG SRC="data:image/png;base64,[the image data in base64]">

For apache 2.0, GOOGLE says it does