On 9/11/2023 6:17 PM, Single Stage to Orbit wrote:
> On Mon, 2023-09-11 at 16:04 -0400, Arne Vajhøj wrote:
>> https://www.theregister.com/2023/09/11/linux_6_6_ksmbd
>>
>> Linux 6.6 is adding SMB server to kernel.
>
> I guess that's SAMBA out of a job then.

We will have to see how it turns out.

TUX did not kill Apache and nginx.

But I think it is a good example of that a lot of stuff
can get added to the kernel if you have an abundance of
developers.

Arne

On 9/11/2023 9:42 AM, plugh wrote:
> I'll propose an explanation for PHP's wide-spread use: websites built
> using rented infrastructure. While you get a choice of OS, one
> usually doesn't get to choose the toolchain for building/deploying
> applications. It's quite rare that one can "easily" deploy an
> application built using a compiler-based toolchain. Far easier to
> upload (ftp> mput src/*) an application built using a script
> language-based toolchain.

It would probably be problematic in that regard to use languages
that compile to native. You can't build on the web hotel and if
you build local then it will be different OS, different OS version,
different C RTL or different something else that prevent it from
running when uploaded.

But it is not a real problem, these kind of languages (static typed
compiled to native) are not suited for web applications anyway.

There are a number of languages being used for web applications.

Several script ones: PHP, Python, Ruby, JavaScript (assuming we do not
consider transpiling ES6 or TS as compilation).

Some that are compiled to byte code and therefor with less
dependency on the platform. This include Java and C#.

PHP still came out on top.

And we can also see many large companies that runs their own data center
still picked PHP.

> For reference, consider the Web developer's
> acronym: LAMP Bemoan it all you want, but here you are.

There are many of those LAMP, LEMP, MEAN, MERN etc.etc..

Arne

On 9/11/2023 1:36 PM, Simon Clubley wrote:
> On 2023-09-11, bill <bill.gunshannon@gmail.com> wrote:
>> On 9/11/2023 9:09 AM, Simon Clubley wrote:
>>> On 2023-09-11, bill <bill.gunshannon@gmail.com> wrote:
>>>> Unless your boss says "I want them on."
>>>
>>> Then you put it in writing why it is such a bad idea and get confirmation
>>> to proceed also in writing. You also CC your coworkers and others so
>>> that when it goes wrong, you can prove you are not to blame.
>>
>> You need to come live in the real world. The boss doesn't need
>> to do anything you want him to do. And bad mouthing him to your
>> coworkers is very likely to just get you fired.

> And who said anything about "bad mouthing" ? That's _NOT_ how this is done.
>
> What you do is to _politely_ and _factually_ write an email confirming
> what you have told to do, and to explain why, by the industry standards,
> this is considered to be a bad thing and what the risks are.
>
> You then ask your boss outright if they want to proceed anyway. This simple
> act may make them reconsider what they asked you to do.
>
> Depending on how serious the thing is you are being asked to do, you may
> also BCC the HR people. They don't care about you (that's not their job),
> but they do care about the company they work for.
>
> By using a BCC, it gives them the option to quietly see if there is a
> problem, and to have a quiet word with your boss, while also giving you
> written confirmation you tried to warn people.
>
> If the company OTOH fires you for this then, _if_ you were polite and
> factual, that company is now in _serious_ trouble, at least in Europe.

In some countries in Europe it is practically impossible to fire
people. In some countries in Europe it is possible to fire people
but they would need to come up with N months of salary.

But no matter the rules, then nothing prevent the boss of
disliking certain employees - and bosses do have something
to say about interesting assignments, relevant training,
promotions, raises etc.etc..

If your boss wants to fire you then even if the law prevents
him from doing so then it is time to start searching for a new
job and a new boss.

As the traditional saying goes:
Employees join companies but leave managers

Arne

On Monday, September 11, 2023 at 4:14:46 PM UTC-7, Arne Vajhøj wrote:
> On 9/11/2023 9:42 AM, plugh wrote:
> > I'll propose an explanation for PHP's wide-spread use: websites built
> > using rented infrastructure. While you get a choice of OS, one
> > usually doesn't get to choose the toolchain for building/deploying
> > applications. It's quite rare that one can "easily" deploy an
> > application built using a compiler-based toolchain. Far easier to
> > upload (ftp> mput src/*) an application built using a script
> > language-based toolchain.
> It would probably be problematic in that regard to use languages
> that compile to native. You can't build on the web hotel and if
> you build local then it will be different OS, different OS version,
> different C RTL or different something else that prevent it from
> running when uploaded.
>
> But it is not a real problem, these kind of languages (static typed
> compiled to native) are not suited for web applications anyway.

That's not true. I use a compiled (Rust) backend to respond to various HTTP POST requests. There's much more to the web than HTML. But you know that.

>
> There are a number of languages being used for web applications.
>
> Several script ones: PHP, Python, Ruby, JavaScript (assuming we do not
> consider transpiling ES6 or TS as compilation).

I think you're making my point for me? Those are all examples of the FTP MPUT {path} deployment technique; which was what I wrote as a reason scripting languages are mostly chosen over compiled; which to you seems to mean translation to machine code/byte code before execution.That excludes PHP encoders (zend, ion cube...); which requires a toolchain build. There's also the PHAR configuration tactic; which can be deployed via FTP
Sadly, on c.o.v. you're omitting Perl. "How the mighty have fallen!"

>
> Some that are compiled to byte code and therefor with less
> dependency on the platform. This include Java and C#.

Agreed. ibid.

>
> PHP still came out on top.

Agreed. LAMP.

>
> And we can also see many large companies that runs their own data center
> still picked PHP.

I can't explain such pathological cases.

> > For reference, consider the Web developer's
> > acronym: LAMP Bemoan it all you want, but here you are.
> There are many of those LAMP, LEMP, MEAN, MERN etc.etc..

Again, making my point for me! Looks like you see the reasons fo PHP's raison d'etre

>
> Arne

On 9/11/2023 8:51 AM, Simon Clubley wrote:
> On 2023-09-09, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> Millions of web sites running PHP indicate that PHP is a good
>> fit for solving web security problems.
>
> It means absolutely nothing of the sort Arne.
>
> All it means is that PHP has a sufficiently large ecosystem that
> it has become established as the "required" language for many
> things regardless of whether or not there are better alternatives.

There is such a thing as inertia when it comes to software. It is not
like everybody is rewriting their software to a new and better
technology the day after the new technology shows up.

But there a few things worth noting.

1) Inertia helps a language on its way out, but makes it
harder for language on its way up. PHP managed to get
its current position back in the 00's by pushing out
older technologies ASP classic, Perl CGI, ColdFusion etc.
and getting ahead of other contenders like ASP.NET and
Java EE. Considering inertia makes PHP in the 00's
even more impressive.

2) Even though inertia help a language on its way out,
then it does not save it. It just lowers the annual
attrition rate. If the applications are used for 10-20-30-40
years then the attrition rate is low and inertia can
keep software around for a very long time. If the applications
are used 2-4-6-8 years then the attrition rate is high and
inertia effect runs out fast. Web applications are one
of the most short lived types of applications. If a web technology
is no longer a top technology then it goes from de facto standard
to niche in less than 10 years. It has not happened to PHP.

3) There are not many languages pushing PHP out. The client side
focus with HTML 5 does not make server side obsolete.
ASP.NET and Java EE has never been a strong competitor in the
low cost market. Python, RoR, Grails etc. came and looked very
promising but stayed niche (Python succeeded hugely in other
markets but not in web applications). The only promising
competitor is node.js. PHP is loosing market share to
node.js - serious market share. But I can't see node.js
replace PHP - node.js is more narrow targeted than PHP.
So it may eat 25% or 33% of PHP's market, but I don't
see it eat 75% or 90%.

> Pretty much like Windows on the desktop.
>
> In fact, thinking about it, PHP is the programming language equivalent
> of Windows.

I don't think you have realized how the desktop market has
worked the last 20 years.

Desktop Linux has been pushed as a competitor against Windows
again and again by those that really like Linux.

But the customers have mostly preferred to pay for Windows (or in
some cases for macOS).

If Linux desktop people had been smart, then they would have
focused a lot on what customers like about Windows and
improved desktop Linux.

But admitting that Windows was better at meeting customers
need was too embarrassing a thought to be considered, so
it became a common refrain along the lines of "desktop
users are just stupid to pick Windows".

As a consequence of that attitude MS was practically
guaranteed to keep Windows's dominant position on the
desktop market.

I believe Windows has been selling for 15-25 B$ every year
the last 20 years.

So the desktop Linux people have given Microsoft a gift
of 300-500 B$ of revenue.

I suspect that Steve Ballmer despite what he says
publicly really loves Linux desktop people. They have
made him very rich!

Arne

On 9/11/2023 7:39 PM, plugh wrote:
> On Monday, September 11, 2023 at 4:14:46 PM UTC-7, Arne Vajhøj
> wrote:
>> On 9/11/2023 9:42 AM, plugh wrote:
>>> I'll propose an explanation for PHP's wide-spread use: websites
>>> built using rented infrastructure. While you get a choice of OS,
>>> one usually doesn't get to choose the toolchain for
>>> building/deploying applications. It's quite rare that one can
>>> "easily" deploy an application built using a compiler-based
>>> toolchain. Far easier to upload (ftp> mput src/*) an application
>>> built using a script language-based toolchain.
>> It would probably be problematic in that regard to use languages
>> that compile to native. You can't build on the web hotel and if you
>> build local then it will be different OS, different OS version,
>> different C RTL or different something else that prevent it from
>> running when uploaded.
>>
>> But it is not a real problem, these kind of languages (static
>> typed compiled to native) are not suited for web applications
>> anyway.
>
> That's not true. I use a compiled (Rust) backend to respond to
> various HTTP POST requests. There's much more to the web than HTML.
> But you know that.

It is possible to write web applications and web services
in such languages.

But it is like tier 4 in the web world. Mostly special cases.

It is not like such languages are never involved, but they are
typical not providing the web interface. More like:

---web server doing proxy and static content---web application/service
in some script language---message queue---backend application in
C++/Java/C#/Python/whatever

>> There are a number of languages being used for web applications.
>>
>> Several script ones: PHP, Python, Ruby, JavaScript (assuming we do
>> not consider transpiling ES6 or TS as compilation).
>
> I think you're making my point for me? Those are all examples of the
> FTP MPUT {path} deployment technique; which was what I wrote as a
> reason scripting languages are mostly chosen over compiled; which to
> you seems to mean translation to machine code/byte code before
> execution.That excludes PHP encoders (zend, ion cube...); which
> requires a toolchain build. There's also the PHAR configuration
> tactic; which can be deployed via FTP Sadly, on c.o.v. you're
> omitting Perl. "How the mighty have fallen!"

Script languages fit nicely with the upload model

But it is all script languages not just PHP.

>> Some that are compiled to byte code and therefor with less
>> dependency on the platform. This include Java and C#.
>
> Agreed. ibid.
>
>> PHP still came out on top.
>
> Agreed. LAMP.
>
>>
>> And we can also see many large companies that runs their own data
>> center still picked PHP.
>
> I can't explain such pathological cases.

But it is quite common.

>>> For reference, consider the Web developer's acronym: LAMP Bemoan
>>> it all you want, but here you are.
>> There are many of those LAMP, LEMP, MEAN, MERN etc.etc..
>
> Again, making my point for me! Looks like you see the reasons fo
> PHP's raison d'etre

Not much PHP in MEAN and MERN.

:-)

Arne

On Mon, 2023-09-11 at 16:39 -0700, plugh wrote:
> Agreed. LAMP.

Rubbing the LAMP won't make things better and more secure :-D
--
Tactical Nuclear Kittens

On 2023-09-11, bill <bill.gunshannon@gmail.com> wrote:
>
> That was one of the funniest articles I have read in a long time.
>

You know Bill, for a country that claims to be a country of rugged
people, many of its citizens don't actually seem to be that robust,
especially these days.

Mind you, given that in the US, you have limited worker protections,
and given the quality of healthcare you receive is tied to your employment
status, I can see why US employees might decide to take an Oliver Twist
submissive workhouse mindset.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2023-09-11, gah4 <gah4@u.washington.edu> wrote:
>
> Maybe I don't know how everyone uses PHP, but the use I have seen is inside HTML.
>
> It is then processed by PHP before it is seen by the HTML parser.
>
> Even more, though PHP has to find its code inside arbitrary HTML, without actually
> parsing HTML.

That's what the PHP open and close tags are for. Anything inside them
is treated as PHP code and anything outside them is not.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 9/12/2023 8:15 AM, Simon Clubley wrote:
> On 2023-09-11, gah4 <gah4@u.washington.edu> wrote:
>> Maybe I don't know how everyone uses PHP, but the use I have seen is inside HTML.
>>
>> It is then processed by PHP before it is seen by the HTML parser.
>>
>> Even more, though PHP has to find its code inside arbitrary HTML, without actually
>> parsing HTML.
>
> That's what the PHP open and close tags are for. Anything inside them
> is treated as PHP code and anything outside them is not.

And it is a pretty standard mechanism.

PHP use <?php ... ?> but other web template systems use
different syntax.

ASP use:
<% ... %> for code snippets
<%= ... %> for expressions

JSP use:
<% ... %> for code snippets
<%= ... %> for expressions
<%! ... %> for type declarations
<%@ ... %> for processor directives

Arne

=?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> wrote:
>
>But I think it is a good example of that a lot of stuff
>can get added to the kernel if you have an abundance of
>developers.

The good thing about Linux is that Linus has to sign off on anything that
gets added to the kernel. So although the kernel has suffered severe bloat,
it has been less than that of some other systems out there.

Unfortunately no such restrictions exist for code in user space.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

On Tuesday, September 12, 2023 at 5:15:44 AM UTC-7, Simon Clubley wrote:
> On 2023-09-11, gah4 <ga...@u.washington.edu> wrote:

> > Maybe I don't know how everyone uses PHP, but the use I have seen is inside HTML.

> > It is then processed by PHP before it is seen by the HTML parser.
> > Even more, though PHP has to find its code inside arbitrary HTML, without actually
> > parsing HTML.

> That's what the PHP open and close tags are for. Anything inside them
> is treated as PHP code and anything outside them is not.

OK, but here is the part that I don't know. Say that the PHP tags are in
quoted strings. Does it still see them? If it isn't parsing HTML, it has
to be sure that it recognizes only the real open and close tags.

On 9/13/2023 9:30 PM, gah4 wrote:
> On Tuesday, September 12, 2023 at 5:15:44 AM UTC-7, Simon Clubley wrote:
>> On 2023-09-11, gah4 <ga...@u.washington.edu> wrote:
>
>>> Maybe I don't know how everyone uses PHP, but the use I have seen is inside HTML.
>
>>> It is then processed by PHP before it is seen by the HTML parser.
>
>>> Even more, though PHP has to find its code inside arbitrary HTML, without actually
>>> parsing HTML.
>
>> That's what the PHP open and close tags are for. Anything inside them
>> is treated as PHP code and anything outside them is not.
>
> OK, but here is the part that I don't know. Say that the PHP tags are in
> quoted strings. Does it still see them? If it isn't parsing HTML, it has
> to be sure that it recognizes only the real open and close tags.

Quotes does not have any special meaning in literal text.

C:\Work>type q.php
"'"'<?php echo "Hi from PHP"; ?>'"'"

C:\Work>php q.php
"'"'Hi from PHP'"'"

Arne

On Wed, 13 Sep 2023 22:19:29 -0400, Arne Vajhøj wrote:

> On 9/13/2023 9:30 PM, gah4 wrote:
>> On Tuesday, September 12, 2023 at 5:15:44 AM UTC-7, Simon Clubley
>> wrote:
>>> On 2023-09-11, gah4 <ga...@u.washington.edu> wrote:
>>
>>>> Maybe I don't know how everyone uses PHP, but the use I have seen is
>>>> inside HTML.
>>
>>>> It is then processed by PHP before it is seen by the HTML parser.
>>
>>>> Even more, though PHP has to find its code inside arbitrary HTML,
>>>> without actually parsing HTML.
>>
>>> That's what the PHP open and close tags are for. Anything inside them
>>> is treated as PHP code and anything outside them is not.
>>
>> OK, but here is the part that I don't know. Say that the PHP tags are
>> in quoted strings. Does it still see them? If it isn't parsing HTML,
>> it has to be sure that it recognizes only the real open and close tags.
>
> Quotes does not have any special meaning in literal text.
>
> C:\Work>type q.php "'"'<?php echo "Hi from PHP"; ?>'"'"
>
> C:\Work>php q.php "'"'Hi from PHP'"'"

How about:

<h2 id="tag<?php>xxxxx</h2> ?

On Thu, 14 Sep 2023 08:39:03 +0000, Bob Eager wrote:

> On Wed, 13 Sep 2023 22:19:29 -0400, Arne Vajhøj wrote:
>
>> On 9/13/2023 9:30 PM, gah4 wrote:
>>> On Tuesday, September 12, 2023 at 5:15:44 AM UTC-7, Simon Clubley
>>> wrote:
>>>> On 2023-09-11, gah4 <ga...@u.washington.edu> wrote:
>>>
>>>>> Maybe I don't know how everyone uses PHP, but the use I have seen is
>>>>> inside HTML.
>>>
>>>>> It is then processed by PHP before it is seen by the HTML parser.
>>>
>>>>> Even more, though PHP has to find its code inside arbitrary HTML,
>>>>> without actually parsing HTML.
>>>
>>>> That's what the PHP open and close tags are for. Anything inside them
>>>> is treated as PHP code and anything outside them is not.
>>>
>>> OK, but here is the part that I don't know. Say that the PHP tags are
>>> in quoted strings. Does it still see them? If it isn't parsing HTML,
>>> it has to be sure that it recognizes only the real open and close
>>> tags.
>>
>> Quotes does not have any special meaning in literal text.
>>
>> C:\Work>type q.php "'"'<?php echo "Hi from PHP"; ?>'"'"
>>
>> C:\Work>php q.php "'"'Hi from PHP'"'"
>
> How about:
>
> <h2 id="tag<?php>xxxxx</h2> ?

Sorry, should be:

<h2 id="tag<?php">xxxxx</h2> ?

On 2023-09-14 10:39, Bob Eager wrote:
> On Thu, 14 Sep 2023 08:39:03 +0000, Bob Eager wrote:
>
>> On Wed, 13 Sep 2023 22:19:29 -0400, Arne Vajhøj wrote:
>>
>>> On 9/13/2023 9:30 PM, gah4 wrote:
>>>> On Tuesday, September 12, 2023 at 5:15:44 AM UTC-7, Simon Clubley
>>>> wrote:
>>>>> On 2023-09-11, gah4 <ga...@u.washington.edu> wrote:
>>>>
>>>>>> Maybe I don't know how everyone uses PHP, but the use I have seen is
>>>>>> inside HTML.
>>>>
>>>>>> It is then processed by PHP before it is seen by the HTML parser.
>>>>
>>>>>> Even more, though PHP has to find its code inside arbitrary HTML,
>>>>>> without actually parsing HTML.
>>>>
>>>>> That's what the PHP open and close tags are for. Anything inside them
>>>>> is treated as PHP code and anything outside them is not.
>>>>
>>>> OK, but here is the part that I don't know. Say that the PHP tags are
>>>> in quoted strings. Does it still see them? If it isn't parsing HTML,
>>>> it has to be sure that it recognizes only the real open and close
>>>> tags.
>>>
>>> Quotes does not have any special meaning in literal text.
>>>
>>> C:\Work>type q.php "'"'<?php echo "Hi from PHP"; ?>'"'"
>>>
>>> C:\Work>php q.php "'"'Hi from PHP'"'"
>>
>> How about:
>>
>> <h2 id="tag<?php>xxxxx</h2> ?
>
> Sorry, should be:
>
> <h2 id="tag<?php">xxxxx</h2> ?

I would say it's not the quotes that are the most relevant in this. The
fact that you are already inside a tag blocks it from being interpreted
as a tag. Quotes or not.

Until the terminating bracken for the <h2, nothing is parsed, unless it
is the specific parsing of the h2 tag.

Johnny

On Thursday, September 14, 2023 at 3:53:54 AM UTC-7, Johnny Billquist wrote:
> On 2023-09-14 10:39, Bob Eager wrote:

(snip)

> > <h2 id="tag<?php">xxxxx</h2> ?

> I would say it's not the quotes that are the most relevant in this. The
> fact that you are already inside a tag blocks it from being interpreted
> as a tag. Quotes or not.
> Until the terminating bracken for the <h2, nothing is parsed, unless it
> is the specific parsing of the h2 tag.

As well as I know it, PHP doesn't know anything about HTML.
It doesn't know any HTML tags, what is inside and what isn't.

That does make it interesting to write an HTML page about PHP.

<title> The <?php and ?> tags.</title>

It reads along until it finds <?php which might be inside something else.

Next question, though, how does it know where the end is? How about:

"'"'<?php echo "closing PHP?>"; ?>'"'"

Once it is parsing PHP, I presume it knows what PHP quotes look like.

On 9/14/2023 4:39 AM, Bob Eager wrote:
> On Thu, 14 Sep 2023 08:39:03 +0000, Bob Eager wrote:
>> How about:
>>
>> <h2 id="tag<?php>xxxxx</h2> ?
>
> Sorry, should be:
>
> <h2 id="tag<?php">xxxxx</h2> ?

That does not contain any PHP code so it is outputted as is.

But:

<h2 id="<?php echo "abc"?>">xxxxx</h2>

outputs:

<h2 id="abc">xxxxx</h2>

Arne

On 9/14/2023 6:53 AM, Johnny Billquist wrote:
> On 2023-09-14 10:39, Bob Eager wrote:
>> On Thu, 14 Sep 2023 08:39:03 +0000, Bob Eager wrote:
>>> How about:
>>>
>>>   <h2 id="tag<?php>xxxxx</h2>     ?
>>
>> Sorry, should be:
>>
>>    <h2 id="tag<?php">xxxxx</h2>     ?
>
> I would say it's not the quotes that are the most relevant in this. The
> fact that you are already inside a tag blocks it from being interpreted
> as a tag. Quotes or not.

No.

PHP is intended to be used with HTML outside <?php ... ?> and
in 99.9% of PHP files it is HTML that is outside <?php ... ?>.

But from a technical perspective then PHP treats what is outside
<?php ... ?> as literal text.

No parsing. Does not care what it is.

And note that even though HTML is sort of the default, then
PHP can instruct the web server that the content is something else.

<h1>xxxxxx</h1>
<?php
echo "yyyyyy\r\n";
?>

vs:

<?php
header("Content-Type: text/plain");
?>
<h1>xxxxxx</h1>
<?php
echo "yyyyyy\r\n";
?>

Arne

On Saturday, September 9, 2023 at 10:08:56 AM UTC-4, Scott Dorsey wrote:
>
> I attempted to get the IT department to actually explain what a computer was
> and what wasn't a computer, and to this day I still cannot get them to give
> me a definition for what a computer is. I blame poor elementary school
> education for this.
> --scott
>
> --
> "C'est un Nagra. C'est suisse, et tres, tres precis."

Well, I don't know what a computer is, but I'm certain a Programmable Data Processor isn't one, so, OK.

--
Steve

On 9/14/2023 2:28 PM, Arne Vajhøj wrote:
> On 9/14/2023 6:53 AM, Johnny Billquist wrote:
>> On 2023-09-14 10:39, Bob Eager wrote:
>>> On Thu, 14 Sep 2023 08:39:03 +0000, Bob Eager wrote:
>>>> How about:
>>>>
>>>>   <h2 id="tag<?php>xxxxx</h2>     ?
>>>
>>> Sorry, should be:
>>>
>>>    <h2 id="tag<?php">xxxxx</h2>     ?
>>
>> I would say it's not the quotes that are the most relevant in this.
>> The fact that you are already inside a tag blocks it from being
>> interpreted as a tag. Quotes or not.
>
> No.
>
> PHP is intended to be used with HTML outside <?php ... ?> and
> in 99.9% of PHP files it is HTML that is outside <?php ... ?>.
>
> But from a technical perspective then PHP treats what is outside
> <?php ... ?> as literal text.
>
> No parsing. Does not care what it is.
>
> And note that even though HTML is sort of the default, then
> PHP can instruct the web server that the content is something else.
>
> <h1>xxxxxx</h1>
> <?php
> echo "yyyyyy\r\n";
> ?>
>
> vs:
>
> <?php
> header("Content-Type: text/plain");
> ?>
> <h1>xxxxxx</h1>
> <?php
> echo "yyyyyy\r\n";
> ?>

In some coding styles it is quite common to have code
inside HTML attributes.

This is just pure PHP code:

$ typ flav1.php
<?php
$opts = array( 'A' => 'This is A', 'B' => 'This is B', 'C' => 'This is C');
echo "<select>\r\n";
foreach($opts as $id => $val) {
echo " <option value='$id'>$val</option>\r\n";
} echo "</select>\r\n";
?>
$ php flav1.php
<select>
<option value='A'>This is A</option>
<option value='B'>This is B</option>
<option value='C'>This is C</option>
</select>

But the same can be done with literal text and smaller PHP fragments:

$ typ flav2.php
<?php
$opts = array( 'A' => 'This is A', 'B' => 'This is B', 'C' => 'This is C');
?>
<select>
<?php
foreach($opts as $id => $val) {
?>
<option value='<?php echo $id; ?>'><?php echo $val;?></option>
<?php
} ?>
</select>
$ php flav2.php
<select>
<option value='A'>This is A</option>
<option value='B'>This is B</option>
<option value='C'>This is C</option>
</select>

Arne