Why would you want to use sed when the Perl regexes are far far far more powerful?

If you feel limited in your command of Perl regexes, I really think that the first thing you want to do is to really start mastering the Perl regexes. Perhaps reading Mastering Regular Expressions, by Jeff Friedl. BTW, this book also shows some of the limitations of regexes, and you project will necessarily meet these limitations. I think that most people on this forum agree that you should not use regexes for parsing HTML or XML, using regexes for parsing PHP would be even worse.

Although regexes might certainly do part of the work, I doubt that you can go anywhere without using a real parser.

One final note on the English-Russian translation anecdote, I personally tried several translating software packages over the years (I was a translator before I became a CS professional) between 1988 and 1996. The results were really bad. On the first one I tried, i gave the following sentence: "Time flies like an arrow". The French translation I obtained was: "Les mouches du temps aiment une flèche", which can be translated back into English as follows: "The flies (the insect) of time love an arrow". I tried other packages at the time, the results were possibly not as funny, but not much better. A lot of improvements have been made since, but the basic problem of implicit context understanding is still there.

Greetings Laurent_R, and thank you for your reply.

"Why would you want to use sed when the Perl regexes are far far far more powerful?

If you feel limited in your command of Perl regexes, I really think that the first thing you want to do is to really start mastering the Perl regexes.

In my humble defense; I made note of this on two occasions early in this thread.

But yes. Agreed.

My choice of referring to SED in this case, is because I can think further with it, because I'm more familiar with it. But assumed that I could (with greater knowledge) accomplish / achive as much with the Perl RE.

Which is why I thought this strategy would work, the way I indicated.

Best wishes, and thanks again for responding.

--Chris

#!/usr/bin/perl -Tw
use Perl::Always or die;
my $perl_version = (5.12.5);
print $perl_version;

In my humble defense; I made note of this on two occasions early in this thread.

I fully appreciate that, and this part of my answer was solely based on your own comments on the subject, I have absolutely no personal opinion on your mastery of regexes.

Just in case I did not explain clearly what I meant, my comment on Perl regexes was really meant to be a friendly advise to your attention with the idea that first spending a couple of weeks working on Perl regexes should probably save you more time in the longer run, on the PHP project especially, but also more generally. I sincerely hope that you did not understand it as me chastising you with something like "do your leaning work and come back once you know it", as nothing could have been further from my mindset. Again, what I said was really meant as a friendly advise, please pardon me if anything I said might have led you to think or suspect otherwise.

I have been using sed and awk and grep, etc. for more than 20 years (although I am certainly not a sed expert the way you are, but more simply a decently trained user), and I still use these utilities quite frequently (I even maintain at my company an intranet wiki with numerous recipes using these utilities), but I have been using these much less than before in the last 5 to 7 years, because I am really convinced that Perl regexes are far more powerful and that Perl one-liners or in-line longer scripts can do (almost) everything that sed can do and much more.

One final point: you might want to look at s2p (sed to Perl) and psed (and a2p, awk to Perl), I would think that they might help you do in Perl what you know how to do in sed and don't yet know how to do in Perl. In addition, looking at the code of these conversion utilities may give you some ideas for your own PHP to Perl project (even though this a much more ambitious project).

There’s no doubt, of course, that valid PHP can be parsed, for syntax checking and so-on, and that once the source has been reduced to an abstract-syntax tree (AST) form, some of those AST constructs could be expanded into Perl.   The languages are in many ways very similar.   You might be able to do such a thing, say, in an editor-macro for a very smart editor.

If you look beyond the superficial, though, you start getting into some much thornier problems.   For example, in the PHP system, “everything is compiled-in,” and is called by means of (hundreds of ...) functions.   Database access, for example, is implemented in that way.   In the Perl system, per contra, we have DBI.   Now you are going to have to develop a way for the translated Perl code to continue doing things “the PHP way.”   Suddenly, your problem has become quite a bit more complicated, and pretty soon “diminishing returns” are going to be a factor.   And then, there are the ideas that simply do not exist at all in Perl, such as the intermingling of HTML and PHP in a file, which was a founding concept of PHP.

"And then, there are the ideas that simply do not exist at all in Perl, such as the intermingling of HTML and PHP in a file, which was a founding concept of PHP."

This is something that's actually incredibly easy to implement. This PHP:

?>Hello<?php
[download]

Becomes this in Perl:

print "Hello";
[download]

There are far harder things to implement - PHP's idea of arrays differs greatly from Perl's; PHP has different ideas about passing arguments to functions by value or reference; different variable scoping; different behaviour of the ==, <, >, etc operators; and so on.

use Moops; class Cow :rw { has name => (default => 'Ermintrude') }; say Cow->new->name

What I mean, Toby, is just that “within the Perl system, most-specifically versus the PHP system,” there is n-o concept of the language-interpreter being “embedded within” a surrounding file “that is to be served.”   Although this concept is a foundation of PHP, I can’t readily recall any other language which does the same thing.

Still, you quite-correctly heap coals upon the same fire:   there are, in fact, a great many differences between the two languages which would make a transliteration between them ... let alone an automatic one ... quite difficult to achieve satisfactorily.   And this may well be the best answer to the OP’s question:   “Even if it could be done, it’s just not worth doing.”   We don’t have to do it.   There is no advantage to be had in picking that particular fight.   We have all of these language systems at our beck-and-call, side by side.   We can, when we need to, make them work together.