shebang skipping in 5.3.0

15 years ago by Joey Smith — view source

unread

I can understand not having the 'shebang skipping' code
in both the SAPI and the scanner, but we probably
need to have it in at least ONE of them. :)

Per his email[1] almost a year ago, Dmitry removed the
shebang line check from sapi/cgi/cgi_main.c in changeset
264153, saying:
Removed shebang line check from CGI sapi (it is
checked by scanner)

In http://tinyurl.com/me8528 (changeset 262275), nlopess
removed the code from the scanner.

Oops?

15 years ago by Joey Smith — view source

unread

Per his email[1] almost a year ago, Dmitry removed the

[1] should have been: http://tinyurl.com/kwne3v

15 years ago by Scott MacVicar — view source

unread

I can understand not having the 'shebang skipping' code
in both the SAPI and the scanner, but we probably
need to have it in at least ONE of them. :)

Per his email[1] almost a year ago, Dmitry removed the
shebang line check from sapi/cgi/cgi_main.c in changeset
264153, saying:
Removed shebang line check from CGI sapi (it is
checked by scanner)

In http://tinyurl.com/me8528 (changeset 262275), nlopess
removed the code from the scanner.

Oops?

What's the problem your having? The skip code is still there just in a
different bit.

Scott

15 years ago by Pierre Joye — view source

unread

See #49182

Cheers,

What's the problem your having? The skip code is still there just in a
different bit.

Scott

--

--
Pierre

http://blog.thepimp.net | http://www.libgd.org

15 years ago by Joey Smith — view source

unread

I definitely had the wrong changeset - sorry, Nuno. :) Looks
like maybe 273177 is the problem child.

http://tinyurl.com/lewcft

I can understand not having the 'shebang skipping' code
in both the SAPI and the scanner, but we probably
need to have it in at least ONE of them. :)

Per his email[1] almost a year ago, Dmitry removed the
shebang line check from sapi/cgi/cgi_main.c in changeset
264153, saying:
Removed shebang line check from CGI sapi (it is
checked by scanner)

In http://tinyurl.com/me8528 (changeset 262275), nlopess
removed the code from the scanner.

Oops?

What's the problem your having? The skip code is still there just in a
different bit.

Scott

15 years ago by Andi Gutmans — view source

unread

Shebang is for command line scripts (php-cli). It does not make sense to
support it for Web server scripts. It just adds unnecessary
code/complexity to that code base. Removing the support from php-cgi was
really a remnant of the old days when cli and cgi were the same SAPI.
I think we are better off this way.

Andi

-----Original Message-----
From: Joey Smith [mailto:joey@joeysmith.com]
Sent: Friday, September 04, 2009 1:35 AM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] shebang skipping in 5.3.0

I definitely had the wrong changeset - sorry, Nuno. :) Looks
like maybe 273177 is the problem child.

http://tinyurl.com/lewcft

I can understand not having the 'shebang skipping' code
in both the SAPI and the scanner, but we probably
need to have it in at least ONE of them. :)

Per his email[1] almost a year ago, Dmitry removed the
shebang line check from sapi/cgi/cgi_main.c in changeset
264153, saying:
Removed shebang line check from CGI sapi (it is
checked by scanner)

In http://tinyurl.com/me8528 (changeset 262275), nlopess
removed the code from the scanner.

Oops?

What's the problem your having? The skip code is still there just in
a
different bit.

Scott

15 years ago by Pierre Joye — view source

unread

hi Andi,

Can you close (bogus) the bug please? Copy this explanation in there as well :)

Cheers,

Shebang is for command line scripts (php-cli). It does not make sense to
support it for Web server scripts. It just adds unnecessary
code/complexity to that code base. Removing the support from php-cgi was
really a remnant of the old days when cli and cgi were the same SAPI.
I think we are better off this way.

Andi

-----Original Message-----
From: Joey Smith [mailto:joey@joeysmith.com]
Sent: Friday, September 04, 2009 1:35 AM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] shebang skipping in 5.3.0

I definitely had the wrong changeset - sorry, Nuno. :) Looks
like maybe 273177 is the problem child.

http://tinyurl.com/lewcft

I can understand not having the 'shebang skipping' code
in both the SAPI and the scanner, but we probably
need to have it in at least ONE of them. :)

Per his email[1] almost a year ago, Dmitry removed the
shebang line check from sapi/cgi/cgi_main.c in changeset
264153, saying:
Removed shebang line check from CGI sapi (it is
checked by scanner)

In http://tinyurl.com/me8528 (changeset 262275), nlopess
removed the code from the scanner.

Oops?

What's the problem your having? The skip code is still there just in
a
different bit.

Scott

--

--

--

--
Pierre

http://blog.thepimp.net | http://www.libgd.org

15 years ago by Jani Taskinen — view source

unread

It's very legit to use with CGI since you might not be able to run PHP any other
way. So this is definately a bug, CGI should handle it the same as CLI.

The bug report clearly explains it too:

http://bugs.php.net/bug.php?id=49182

--Jani

Andi Gutmans wrote:

Shebang is for command line scripts (php-cli). It does not make sense to
support it for Web server scripts. It just adds unnecessary
code/complexity to that code base. Removing the support from php-cgi was
really a remnant of the old days when cli and cgi were the same SAPI.
I think we are better off this way.

Andi

-----Original Message-----
From: Joey Smith [mailto:joey@joeysmith.com]
Sent: Friday, September 04, 2009 1:35 AM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] shebang skipping in 5.3.0

I definitely had the wrong changeset - sorry, Nuno. :) Looks
like maybe 273177 is the problem child.

http://tinyurl.com/lewcft

I can understand not having the 'shebang skipping' code
in both the SAPI and the scanner, but we probably
need to have it in at least ONE of them. :)

Per his email[1] almost a year ago, Dmitry removed the
shebang line check from sapi/cgi/cgi_main.c in changeset
264153, saying:
Removed shebang line check from CGI sapi (it is
checked by scanner)

In http://tinyurl.com/me8528 (changeset 262275), nlopess
removed the code from the scanner.

Oops?
What's the problem your having? The skip code is still there just in
a
different bit.

Scott

15 years ago by Pierre Joye — view source

unread

I'm not totally convinced by this argument. CGI is definitively a
different SAPI than CLI and can behave differently. It was a problem
before when we had only one command for both CLI and CGI, but that's
not the case anymore.

We should better document CLI and recommend to always install it shell
usage is planed (and distros should install it by default as well).

It's very legit to use with CGI since you might not be able to run PHP any
other way. So this is definately a bug, CGI should handle it the same as
CLI.

The bug report clearly explains it too:

http://bugs.php.net/bug.php?id=49182

--Jani

Andi Gutmans wrote:

Shebang is for command line scripts (php-cli). It does not make sense to
support it for Web server scripts. It just adds unnecessary
code/complexity to that code base. Removing the support from php-cgi was
really a remnant of the old days when cli and cgi were the same SAPI.
I think we are better off this way.

Andi

-----Original Message-----
From: Joey Smith [mailto:joey@joeysmith.com]
Sent: Friday, September 04, 2009 1:35 AM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] shebang skipping in 5.3.0

I definitely had the wrong changeset - sorry, Nuno. :) Looks
like maybe 273177 is the problem child.

http://tinyurl.com/lewcft

I can understand not having the 'shebang skipping' code
in both the SAPI and the scanner, but we probably
need to have it in at least ONE of them. :)

Per his email[1] almost a year ago, Dmitry removed the
shebang line check from sapi/cgi/cgi_main.c in changeset
264153, saying:
Removed shebang line check from CGI sapi (it is
checked by scanner)

In http://tinyurl.com/me8528 (changeset 262275), nlopess
removed the code from the scanner.

Oops?

What's the problem your having? The skip code is still there just in

a

different bit.

Scott

--

--

--

--
Pierre

http://blog.thepimp.net | http://www.libgd.org

15 years ago by Jani Taskinen — view source

unread

You obviously don't understand at all what this is used for.
Consider the case where you can't change webserver's configs.
Or that you want to quickly test different PHP versions.
What would be easier than simply switching the version in the shebang line?
Quite legitimate and useful to me. And this has NOTHING to do with CLI.

--Jani

Pierre Joye wrote:

I'm not totally convinced by this argument. CGI is definitively a
different SAPI than CLI and can behave differently. It was a problem
before when we had only one command for both CLI and CGI, but that's
not the case anymore.

We should better document CLI and recommend to always install it shell
usage is planed (and distros should install it by default as well).

It's very legit to use with CGI since you might not be able to run PHP any
other way. So this is definately a bug, CGI should handle it the same as
CLI.

The bug report clearly explains it too:

http://bugs.php.net/bug.php?id=49182

--Jani

Andi Gutmans wrote:

Shebang is for command line scripts (php-cli). It does not make sense to
support it for Web server scripts. It just adds unnecessary
code/complexity to that code base. Removing the support from php-cgi was
really a remnant of the old days when cli and cgi were the same SAPI.
I think we are better off this way.

Andi

-----Original Message-----
From: Joey Smith [mailto:joey@joeysmith.com]
Sent: Friday, September 04, 2009 1:35 AM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] shebang skipping in 5.3.0

I definitely had the wrong changeset - sorry, Nuno. :) Looks
like maybe 273177 is the problem child.

http://tinyurl.com/lewcft

I can understand not having the 'shebang skipping' code
in both the SAPI and the scanner, but we probably
need to have it in at least ONE of them. :)

Per his email[1] almost a year ago, Dmitry removed the
shebang line check from sapi/cgi/cgi_main.c in changeset
264153, saying:
Removed shebang line check from CGI sapi (it is
checked by scanner)

In http://tinyurl.com/me8528 (changeset 262275), nlopess
removed the code from the scanner.

Oops?
What's the problem your having? The skip code is still there just in
a
different bit.

Scott

15 years ago by Pierre Joye — view source

unread

You obviously don't understand at all what this is used for.
Consider the case where you can't change webserver's configs.
Or that you want to quickly test different PHP versions.
What would be easier than simply switching the version in the shebang line?
Quite legitimate and useful to me. And this has NOTHING to do with CLI.

I do and I still don't agree. This edge case is not worth the effort
to maintain this feature for CGI.

Cheers,

Pierre

http://blog.thepimp.net | http://www.libgd.org

15 years ago by Jani Taskinen — view source

unread

Pierre Joye wrote:

You obviously don't understand at all what this is used for.
Consider the case where you can't change webserver's configs.
Or that you want to quickly test different PHP versions.
What would be easier than simply switching the version in the shebang line?
Quite legitimate and useful to me. And this has NOTHING to do with CLI.

I do and I still don't agree. This edge case is not worth the effort
to maintain this feature for CGI.

BC. Need I say more?

--Jani

15 years ago by Tom Boutell — view source

unread

Surprisingly, the CGI programming book I wrote in 1995 is relevant to
this conversation. (:

We're forgetting our history here.

CGI = Common Gateway Interface = web servers running stuff as normal
executables. That means, yes, shebang path support is important!

It's great that modern web servers can be configured to automatically
recognize .php and run the PHP interpreter without the extra step of
the OS interpreting the shebang. But that's not mandatory. If it's
mandatory, you better stop calling it CGI.

Without shebang support, it's incompatible with perfectly valid CGI
implementations. And that means it's broken as a SAPI for CGI.

You obviously don't understand at all what this is used for.
Consider the case where you can't change webserver's configs.
Or that you want to quickly test different PHP versions.
What would be easier than simply switching the version in the shebang line?
Quite legitimate and useful to me. And this has NOTHING to do with CLI.

--Jani

Pierre Joye wrote:

I'm not totally convinced by this argument. CGI is definitively a
different SAPI than CLI and can behave differently. It was a problem
before when we had only one command for both CLI and CGI, but that's
not the case anymore.

We should better document CLI and recommend to always install it shell
usage is planed (and distros should install it by default as well).

It's very legit to use with CGI since you might not be able to run PHP
any
other way. So this is definately a bug, CGI should handle it the same as
CLI.

The bug report clearly explains it too:

http://bugs.php.net/bug.php?id=49182

--Jani

Andi Gutmans wrote:

Shebang is for command line scripts (php-cli). It does not make sense to
support it for Web server scripts. It just adds unnecessary
code/complexity to that code base. Removing the support from php-cgi was
really a remnant of the old days when cli and cgi were the same SAPI.
I think we are better off this way.

Andi

-----Original Message-----
From: Joey Smith [mailto:joey@joeysmith.com]
Sent: Friday, September 04, 2009 1:35 AM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] shebang skipping in 5.3.0

I definitely had the wrong changeset - sorry, Nuno. :) Looks
like maybe 273177 is the problem child.

http://tinyurl.com/lewcft

I can understand not having the 'shebang skipping' code
in both the SAPI and the scanner, but we probably
need to have it in at least ONE of them. :)

Per his email[1] almost a year ago, Dmitry removed the
shebang line check from sapi/cgi/cgi_main.c in changeset
264153, saying:
Removed shebang line check from CGI sapi (it is
checked by scanner)

In http://tinyurl.com/me8528 (changeset 262275), nlopess
removed the code from the scanner.

Oops?

What's the problem your having? The skip code is still there just in

a

different bit.

Scott

--

--

--

--

--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com

15 years ago by Pierre Joye — view source

unread

Surprisingly, the CGI programming book I wrote in 1995 is relevant to
this conversation. (:

We're forgetting our history here.

It would be really nice if everyone could consider that the other do
understand what is being discussed but actually disagree. The question
was actually: is it worth the effort? Who is seriously using CGI (not
meaning fastcgi) with php these days?

Cheers,

Pierre

http://blog.thepimp.net | http://www.libgd.org

15 years ago by Marco Tabini — view source

unread

It would be really nice if everyone could consider that the other do
understand what is being discussed but actually disagree. The question
was actually: is it worth the effort? Who is seriously using CGI (not
meaning fastcgi) with php these days?

On shared hosts, CGI is often the only way to have your own custom
version of PHP. I don't know if that's relevant to this conversation,
though :-)

Mt.

15 years ago by Tom Boutell — view source

unread

Pardon, I do realize everyone remembers CGI, but sometimes it's
important to review the basics, especially when optimized variants are
more popular than the original (but have by no means eliminated it).

Classic CGI has its advantages. It's simple to implement and memory
leaks in individual instances don't matter. Embedded devices still use
it quite a lot.

Classic CGI is also an interesting transitional strategy when you're
replacing a mixed bag of Perl, C and other CGI programs. Making it
harder to transition to PHP isn't good for PHP. This is the "Common"
part of CGI and shouldn't be forgotten.

At any rate, it doesn't make sense to deliver a SAPI for "CGI" on Unix
platforms that doesn't do shebang paths and therefore doesn't actually
work in a classic CGI environment. Call it "PGI" if you must delete
that feature.

It would be really nice if everyone could consider that the other do
understand what is being discussed but actually disagree. The question
was actually: is it worth the effort? Who is seriously using CGI (not
meaning fastcgi) with php these days?

On shared hosts, CGI is often the only way to have your own custom version
of PHP. I don't know if that's relevant to this conversation, though :-)

Mt.

--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com

15 years ago by Andi Gutmans — view source

unread

-----Original Message-----
From: Tom Boutell [mailto:tom@punkave.com]
Sent: Saturday, September 05, 2009 6:30 AM
To: Marco Tabini
Cc: Pierre Joye; jani.taskinen@iki.fi; Andi Gutmans; Joey Smith;
internals@lists.php.net
Subject: Re: [PHP-DEV] shebang skipping in 5.3.0

-snip-

Classic CGI has its advantages. It's simple to implement and memory
leaks in individual instances don't matter. Embedded devices still use
it quite a lot.

Classic CGI is also an interesting transitional strategy when you're
replacing a mixed bag of Perl, C and other CGI programs. Making it
harder to transition to PHP isn't good for PHP. This is the "Common"
part of CGI and shouldn't be forgotten.

If this is indeed a use-case for CGI then I think it's a valid argument
and we are probably better off supporting it. I did not remember shebang
works for real CGI.
There are still plenty of use-cases for running CGI (as opposed to
FastCGI) in the industry.
Question now is whether this should be done in the scanner or in the
SAPI. I'll check with Dmitry who made this change.

Andi

15 years ago by Keisial — view source

unread

Andi Gutmans wrote:

If this is indeed a use-case for CGI then I think it's a valid argument
and we are probably better off supporting it. I did not remember shebang
works for real CGI.
There are still plenty of use-cases for running CGI (as opposed to
FastCGI) in the industry.
Question now is whether this should be done in the scanner or in the
SAPI. I'll check with Dmitry who made this change.

Andi

Probably in sapi, so it only affects cgi and cli, and doesn't
reintroduce bug 46844.
OTOH, skipping shebang on included files could be a feature, if someone
uses cgi and uses
files both as entrypoint and included scripts.
A compromise might be skipping shebang line only when it's followed by
<?php, but it's hackish.

15 years ago by Pierre Joye — view source

unread

Hi,

For the record here, as far as I can see, the bugs have been fixed by
Jani. Please go testing and report any reminding issues :)

Cheers,

Andi Gutmans wrote:

If this is indeed a use-case for CGI then I think it's a valid argument
and we are probably better off supporting it. I did not remember shebang
works for real CGI.
There are still plenty of use-cases for running CGI (as opposed to
FastCGI) in the industry.
Question now is whether this should be done in the scanner or in the
SAPI. I'll check with Dmitry who made this change.

Andi

Probably in sapi, so it only affects cgi and cli, and doesn't
reintroduce bug 46844.
OTOH, skipping shebang on included files could be a feature, if someone
uses cgi and uses
files both as entrypoint and included scripts.
A compromise might be skipping shebang line only when it's followed by
<?php, but it's hackish.

--

--
Pierre

http://blog.thepimp.net | http://www.libgd.org

15 years ago by Richard Lynch — view source

unread

A compromise might be skipping shebang line only when it's followed by
<?php, but it's hackish.

Bad idea.

I had one #! script that dumped out some HTML first.

I think it was a static-file-generator type of thing.

And the same file was used when no static file was available, as I
recall...

Maybe not, though, as the logic for that would have preceded the #!

God, this was ages ago when webhosts actually almost always gave you
CGI and mod_php was too shiny new to be trusted...

--
Some people ask for gifts here.
I just want you to buy an Indie CD for yourself:
http://cdbaby.com/search/from/lynch

15 years ago by jvlad — view source

unread

If this is indeed a use-case for CGI then I think it's a valid argument
and we are probably better off supporting it. I did not remember shebang
works for real CGI.
There are still plenty of use-cases for running CGI (as opposed to
FastCGI) in the industry.
Question now is whether this should be done in the scanner or in the
SAPI. I'll check with Dmitry who made this change.

Andi

yes, some servers are still running php as CGI. But it is not only CGI
standard involved.

Well, to have a script running as a CGI, shell is executed. That's why it's
necessary to have execute file permissions, that's why shebang looks like
any other shell shebangs:
#!whateverhandler whateverargument
In other words, shebangs are SHELL INSTRUCTIONS and have nothing to do with
CGI at all, or more precisely CGI is just one case where shebang is useful.
With shebang any php script can be run via shell, as if it was an
executable, so it is useful, not only in case of CGI.

As I see it, the problem stems from fact that shebangs in php scripts are
always located in the HTML part. Otherwise they would be ignored by PHP as
regular comments and no problems would arise. So, special handling should be
done in PHP to IGNORE shebangs.
Better to have this done in lexer. Why? Because the same scripts can be run
using cron (via shell), apache module, console (via shell), and CGI.

just my 2c.

-jv

15 years ago by jvlad — view source

unread

From: "Richard Quadling" rquadling@googlemail.com
Newsgroups: php.internals
Sent: Monday, September 07, 2009 3:44 PM
Subject: Re: [PHP-DEV] shebang skipping in 5.3.0

2009/9/7 jvlad dmda@yandex.ru:

And for windows, the shebang line is not used. So becomes part of the
output - no matter what SAPI is used.

Unless PHP removes/ignores it.

In fact, I can see no reason at all why PHP should output that line if
it is the first line of the first script being processed.

I think things get messy when the first script includes completed PHP
scripts which MAY be standalone scripts.

Say you had task1.php, task2.php, etc. All runnable by themselves.

Now, say you had tasks.php which simply included task1.php, task2.php,
etc.

If all have shebangs, then the first one SHOULD be removed, but the
others ...

Initially yes, but how do you differentiate between a php script
(which may or may not have a .php extension) and a file whose first
line is a shebang - say because it is an example script or a fluke in
the file ...

Right, you can have a php script in a file without any extensions at all.
Shebang will tell shell what interpreter is to execute.
But why would I or anybody else need to differentiate the files by their
extensions?
The answer is because it's slightly faster. You don't have to read file
content to make decision
what to do with the file.
It's what php's Apache module is doing. Apache configuration file associates
.php file extension with appropriate MIME type, then php handler will be
called
in case if such file is requested.
But, with almost the same success you could establish an association between
php scripts and
php handler by the file content.
See magic file distributed with Apache :) and mod_mime_magic docs.

I see no reason why #!/blahblahblah should appear in the output 1st line at
the leftmost position.
Even in the marginal case when you just want to show a sample of a script
with shebang, you'd have to add
some tags before the line, like below:

<body><pre>#!/blhablahblah...

and finally you can do this with echo:
<?php
echo "#!/blahblahblah";
?>
kinda trivial thing.

I think all shebangs should be removed, regardless they appear in the
initial script or in the included ones.

-jv

15 years ago by dreamcat four — view source

unread

Hi,
Can this snippet of shebang checking be removed for php 5.3.+, 6?
Its for external FPM project.

cgi_main.c:
php_fopen_primary_script(&file_handle TSRMLS_CC);

	if (CGIG(check_shebang_line) && file_handle.handle.fp &&

(file_handle.handle.fp != stdin)) {
/* #!php support /
c = fgetc(file_handle.handle.fp); / <------- SEGFAULT /
if (c == '#') {
while (c != '\n' && c != '\r' && c != EOF) {
c = fgetc(file_handle.handle.fp); / skip to end of line /
}
/ handle situations where line is terminated by \r\n */
if (c == '\r') {
if (fgetc(file_handle.handle.fp) != '\n') {
long pos = ftell(file_handle.handle.fp);
fseek(file_handle.handle.fp, pos - 1, SEEK_SET);
}
}
CG(start_lineno) = 2;
} else {
rewind(file_handle.handle.fp);
}
}

fpm_request_executing();
php_execute_script(&file_handle TSRMLS_CC);

Reference:
http://marc.info/?l=php-internals&m=121759090811279&w=2

Many thanks in advance,

dreamcat4
dreamcat4@gmail.com

15 years ago by jvlad — view source

unread

Hi,
Can this snippet of shebang checking be removed for php 5.3.+, 6?
Its for external FPM project.

cgi_main.c:
php_fopen_primary_script(&file_handle TSRMLS_CC);

if (CGIG(check_shebang_line) && file_handle.handle.fp &&
(file_handle.handle.fp != stdin)) {
/* #!php support /
c = fgetc(file_handle.handle.fp); / <------- SEGFAULT */

Hi dreamcat four,

Before accessing .handle.fp, you'd check type field
It can be either ZEND_HANDLE_FILENAME, or ZEND_HANDLE_FD, or ZEND_HANDLE_FP,
or finally ZEND_HANDLE_STREAM.
in case of ZEND_HANDLE_STREAM you'd avoid accessing .fp field.
in case of ZEND_HANDLE_FD, you deal with file descriptor (int),
in case of ZEND_HANDLE_FP, you deal with FILE* handle in the .fp field,
in case of ZEND_HANDLE_FILENAME you have only filename and you can open it
using zend_stream_open() (or zend_fopen in case of php4).

Regarding shebang checks to be removed or not, it's up to Andi and Dmitry.
They are making decision whether this check should be done in the lexer or
in SAPI.

In former case, you'd remove the check, and leave it otherwise.

Regards,
jv

15 years ago by Jani Taskinen — view source

unread

Marco Tabini wrote:

It would be really nice if everyone could consider that the other do
understand what is being discussed but actually disagree. The question
was actually: is it worth the effort? Who is seriously using CGI (not
meaning fastcgi) with php these days?

On shared hosts, CGI is often the only way to have your own custom
version of PHP. I don't know if that's relevant to this conversation,
though :-)

It's quite relevant. It's actually one of the most important things I tried to
explain Pierre already. And yes, people still use CGI these days. Not all of
them have their own webservers running they can configure however they wish.

--Jani

15 years ago by Pierre Joye — view source

unread

It's quite relevant. It's actually one of the most important things I tried
to explain Pierre already. And yes, people still use CGI these days. Not all
of them have their own webservers running they can configure however they
wish.

Well, then fix it and provide a patch :) If it does not hurt, it can be applied.

Cheers,

Pierre

http://blog.thepimp.net | http://www.libgd.org

15 years ago by Keisial — view source

unread

Andi Gutmans wrote:

Shebang is for command line scripts (php-cli). It does not make sense to
support it for Web server scripts. It just adds unnecessary
code/complexity to that code base. Removing the support from php-cgi was
really a remnant of the old days when cli and cgi were the same SAPI.
I think we are better off this way.

Andi

Why doesn't is make sense? It is a legitimate usage, and if novody used
it, it wouldn't have noticed.

Case 4: PHP parser outside of web tree
A very secure option is to put the PHP parser binary somewhere outside
of the web tree of files. In /usr/local/bin, for example. The only
real downside to this option is that you will now have to put a line
similar to:

#!/usr/local/bin/php

as the first line of any file containing PHP tags. You will also need
to make the file executable. That is, treat it exactly as you would
treat any other CGI script written in Perl or sh or any other common
scripting language which uses the /#!/ shell-escape mechanism for
launching itself.

http://php.net/manual/en/security.cgi-bin.shell.php

15 years ago by Richard Lynch — view source

unread

Shebang is for command line scripts (php-cli). It does not make sense
to
support it for Web server scripts. It just adds unnecessary
code/complexity to that code base. Removing the support from php-cgi
was
really a remnant of the old days when cli and cgi were the same SAPI.
I think we are better off this way.

At the risk of being ridiculed...

I have, in the past, had a script that worked both as a web page and
as a CGI (now CLI) script.

Granted, it's pretty trivial to just do an include in one or the
other, but I actually used the feature of #! being removed in mod_php
SAPI, once upon a time.

It may even still be in some legacy code out there for me.

--
Some people ask for gifts here.
I just want you to buy an Indie CD for yourself:
http://cdbaby.com/search/from/lynch