[PHP-DEV] Re: PHP 8.0.13 Released

[Sara Golemon]

On Thu, Nov 18, 2021 at 9:16 PM Sara Golemon  wrote:

> The PHP development team announces the immediate availability of PHP
> 8.0.13. This is a security release fixing CVE-2021-21706.
>
>
Whoops. Apologies for the copypasta error. That CVE number is a typo and
should read CVE- 2021-21707 for https://bugs.php.net/79971

-Sara

[PHP-DEV] PHP 8.0.13 Released

[Sara Golemon]

The PHP development team announces the immediate availability of PHP
8.0.13. This is a security release fixing CVE-2021-21706.

For source downloads of PHP 8.0.13 please visit our downloads page:
https://www.php.net/downloads
Windows source and binaries can be found at https://windows.php.net/download
The list of changes is recorded in the ChangeLog:
https://www.php.net/ChangeLog-8.php

Many thanks to all the contributors and supporters!
Sara Golemon and Gabriel Caruso

Release Manifest here and below:
https://gist.github.com/sgolemon/3964ae5f68cc06798bc99497821540ef

php-8.0.13.tar.gz
SHA256 hash:
b4c2d27c954e1b0d84fd4bfef4d252e154ba479e7db11abd89358f2164ee7cc8
PGP signature:
-BEGIN PGP SIGNATURE-

iQJEBAABCgAuFiEEFyn4OTjaROJ7oPTT29s5dHDRIXIFAmGUGpQQHHBvbGxpdGFA
cGhwLm5ldAAKCRDb2zl0cNEhctBQD/9n90Vm3RE5i4rii12y+CUw76X+80ep8ASp
xd/eHDn5heNj2redkfYy0yK5ZxR96ZG7b9Seb/LTXfiwstJS2UffSq4Rv1HUJtqZ
eoQkrHS3Bmg6fRKpY6CLj0iRoJxWwson68uj9Son0GY0uk0rDMn/J7+y8kv862wj
QcZj4lyhPmyIu1Egk8lPTnUxdbvPqC8MZjQ7XfreoTVwM7zIfzTbByqjVgH41bIw
HndFz7Hu7fU/W0azQMQZW0uZUrqlnaWkUbb4AzywebBYexuJI4O3RuUcUyQ5g37p
nX77g6smOb9W0Uh5DhLHDLZxF7wDNinc97QxgKuL1GZSBNuVMYAYKEMy9FERjHXG
DkOlpyr+w3gYg1Z6k+NL1GIHMi/JWnOvj8N5Co5G3ZEqJd3yRBulJHBxx2sAD2Bt
EYu9uglrvXUrUqCwvqJRt91YOFs7kZy1t8ZRD2sG3IAMNEQeh12Ak5NWMLK6+HFV
w/mqQDnYcZNC/qLIAIqRODt3Zb6darwfug7cQUtZfw38B4kkfUVbhUvE7iTfJgXw
vOHZHlvfvun9ugN0Fv+6EfST5ga6ol+eIgakMXUdGuLqnVrkHxJODdRXewRAGrpm
NAcgFUy2LdNK2k/3oUE9uekwEoqFhNljWAGU02PFAazJBOk8c+HUjSZLEp73Zq/i
qMqQf7gJCw==
=ZAr9
-END PGP SIGNATURE-

php-8.0.13.tar.bz2
SHA256 hash:
c2419d7ba4395f44747043f4e6f5b47fa08125705fb9f88377e453068a815836
PGP signature:
-BEGIN PGP SIGNATURE-

iQJEBAABCgAuFiEEFyn4OTjaROJ7oPTT29s5dHDRIXIFAmGUGpcQHHBvbGxpdGFA
cGhwLm5ldAAKCRDb2zl0cNEhclrNEADAYooqUPVyJuYWBaD6g42h9LofrsObLybv
/afntIKYo1ogG7i6NHpCXKwNK/yW5CC010MVzQsVSbjmrwRXtNjqtSD344bSHhrs
ImAHfUWMVQkn/nWkdLc2MdEbxO7IohdoAQ9jfQSgZp4X8NLZTrA+ayDLc/nYZpSe
TWswS05ucubMneFkFAs/uqotvH/5W8W2jY/NVmigeD1qAikjaJaNjk45TxYvykI2
9EkplRQrguAxBlJXvzPbeeajV55f7p+0OwlXI4TI4YYpctLWff0xfsIhrnt/h6Px
a7J7alPYIHTQxot80jXsXheJvIp1BiI0J2Es2Nv+gl0gsWw78sZ887kC9X3A2uit
TOVisilJ7hSCqCH3oaAvxVjK272c04EC0Cm826IyWGidHtcVbB9+Cf89mnrP/d4K
cdg6EDwk7QJLl0nfVLyJahWUZ5Roe1PjJOwbxS/ss02iy3jLVZE6ZMTQN1TVEawC
GtlrTdieqnoLYpjq91NY17u/HKgXXOynukbu+kCSaS9v6fezermZHqkZp+YK8xrs
kKYbnxWsB0HKxXcyP4/Vglw13KiuyRT/WzSF+6VLTomrXdax3Ty82aZAbAyGtf0H
7zjgksVbalqafRv+UGsoRfXdGgqMG3HQaFLJLm9crQ8UC+I/Sx1yBro8hM48ccOR
vXbpF5ReTw==
=dyYt
-END PGP SIGNATURE-

php-8.0.13.tar.xz
SHA256 hash:
cd976805ec2e9198417651027dfe16854ba2c2c388151ab9d4d268513d52ed52
PGP signature:
-BEGIN PGP SIGNATURE-

iQJEBAABCgAuFiEEFyn4OTjaROJ7oPTT29s5dHDRIXIFAmGUGpcQHHBvbGxpdGFA
cGhwLm5ldAAKCRDb2zl0cNEhcuMrD/9c6os7ZNv/cS5I3arv5jvMvogp+ROkHNcd
NPB+JOjIDVOReKEWYImwhJv2/tD7VdItJTA7drHK8n419nGq0qywyyQuu6aRgUTF
d2hE4+49fnQjcwZ+Bz/tM2maJ5jy0yZN6lkdBkO8lOXUAEqwPvdaZUl3mjrgPI5k
MYXidRBvNcioNqHOVkYZ9wzsuGiN81TBU/MreEPBMcaht5agautVw9XMnqJ13pZB
jnJxCgWUggvpu8KPKNCtTWOVlegkUqi13+GO6J9U2fEYb7be8edMXlTaJWXZkd9H
VlKlN+/4eXvcRQxzhmxilDpZfYhvmivj/34r3Ox1JYBHS59VCFztMLl4+7cl7D/y
z/L7U6xHlxW0O2xa6XM1SSUxxIRw8De+2FkFuWCWAkMxJefBqy+fb9jSGqB/gxys
T2vQdMvswMp0LPmhYjwOyvNXc3TCvPIRxyvdtRqMaAe3IUqkA+B81QTB2kzNPJz3
8L5t5FR5fLFuIgUGkdE7odStCakriJjsyNRAuSTzJ/X4UzMmUI7cMWpPuJ2PKzBl
ecK6DB9wBGNQfm4mvlS1vtov4XDGPRmZNx+hnad8seJpGLQ/7kAwbw9XMcvPcOkU
QfI8IZbSSF7et2Dwup8YrWRG8RrJY5MI4I5xGKYQD/WoygS9yLLrqy+kapo0ajYy
0bqxeMLb9g==
=+AGI
-END PGP SIGNATURE-

[PHP-DEV] PHP 8 Release Announcement Page

[Sara Golemon]

In seven days, https://www.php.net/releases/8.0/en.php is going to be
obsolete.

Well, that's a harsh term, but it certainly won't reflect the current state
on the ground, and we need to decide (should have decided, weeks ago) what
we're going to do with it.

1/ Make a new announcement page for 8.1 ? Effort: High, Impact: Awesome
2/ Update the 8.0 page? Effort: Moderate, Impact: Still relatively awesome
3/ Remove the link from the banner (but still keep the page for archival
purposes). Effort: Low, Impact: Shrugs all around
4/ Remove the link AND the page. Effort: Low, Impact: But... why?

Personally, I've not got the cycles for 1 or 2, so I vote 3.  Anyone care
to do more?  Bear in mind translations will be wanted.  If nobody steps up,
then I'll plan on implementing #3 next Wednesday.

-Sara

Re: [PHP-DEV] Re: [RFC] Migrating to GitHub issues

[Christoph M. Becker]

On 18.11.2021 at 15:19, Nikita Popov wrote:

> On Thu, Nov 18, 2021 at 2:53 PM Matthew Weier O'Phinney <
> mweierophin...@gmail.com> wrote:
>
>> With Laminas, we use an email alias to allow researchers to report to us.
>> We then post the full report as a security issue on GitHub - it's a feature
>> they rolled out late 2019/early 2020 that restricts visibility to
>> maintainers initially, but allows inviting others to collaborate (we invite
>> the reporter immediately, for instance). It also creates a private branch
>> for collaboration. When the patch has been merged, you can mark the issue
>> public.
>
> Thanks for the suggestion! That does sound generally viable to me. Just to
> clarify, this is not making use of issues, but rather of "advisories",
> which GH implements as an independent feature.
>
> I'm not involved in security response, so I can't say whether the security
> group would want to adopt such a process. This is probably something that
> should be decided among the people who handle security issues, rather than
> here.

Yeah, I suggest to decouple the security reporting issue from this RFC.
 That can and should be decided by other people, and wouldn't need an
RFC, in my opinion.

Just a quick note here, that the handling of security reports is rather
suboptimal on bugsnet.  Patches need to be shared via secrets Gists (or
similar) since even the reporter can't access attached patches.

--
Christoph M. Becker

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] Migrating to GitHub issues

[Nikita Popov]

On Thu, Nov 18, 2021 at 2:53 PM Matthew Weier O'Phinney <
mweierophin...@gmail.com> wrote:

>
>
> On Thu, Nov 18, 2021, 7:32 AM Nikita Popov  wrote:
>
>> On Thu, Nov 18, 2021 at 2:07 PM Patrick ALLAERT 
>> wrote:
>>
>> > Le mer. 17 nov. 2021 à 13:30, Christoph M. Becker  a
>> > écrit :
>> > > Right.  An alternative might be to let users report security issues to
>> > > the security mailing list, where, if the issue turns out not to be a
>> > > security issue, the reporter could still be asked to submit a GH issue
>> > > about the bug.  In that case it might be useful to add more devs to
>> the
>> > > security mailing list.
>> >
>> > I was thinking about the same. Can't we work with security issues with
>> > mailing list *only*?
>> > It doesn't feel optimal to keep bugs.php.net active for just security
>> > ones.
>> > I miss seeing the motivation for it.
>> >
>>
>> The problem with the security mailing list is that it's ephemeral --
>> someone new can't look at past discussions before they were subscribed.
>> Additionally, it's not possible to make the issue and the whole
>> conversation around it public after the issue has been fixed.
>>
>
> With Laminas, we use an email alias to allow researchers to report to us.
> We then post the full report as a security issue on GitHub - it's a feature
> they rolled out late 2019/early 2020 that restricts visibility to
> maintainers initially, but allows inviting others to collaborate (we invite
> the reporter immediately, for instance). It also creates a private branch
> for collaboration. When the patch has been merged, you can mark the issue
> public.
>

Thanks for the suggestion! That does sound generally viable to me. Just to
clarify, this is not making use of issues, but rather of "advisories",
which GH implements as an independent feature.

I'm not involved in security response, so I can't say whether the security
group would want to adopt such a process. This is probably something that
should be decided among the people who handle security issues, rather than
here.

Regards,
Nikita

Re: [PHP-DEV] Re: [RFC] Migrating to GitHub issues

[Christoph M. Becker]

On 18.11.2021 at 14:53, Matthew Weier O'Phinney wrote:

> With Laminas, we use an email alias to allow researchers to report to us.
> We then post the full report as a security issue on GitHub - it's a feature
> they rolled out late 2019/early 2020 that restricts visibility to
> maintainers initially, but allows inviting others to collaborate (we invite
> the reporter immediately, for instance). It also creates a private branch
> for collaboration. When the patch has been merged, you can mark the issue
> public.
>
> If the plan is to move to GH anyways, this could solve security reporting.

Thanks!  I wasn't aware of that feature.  More info at
.

--
Christoph M. Becker

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] Migrating to GitHub issues

[Matthew Weier O'Phinney]

On Thu, Nov 18, 2021, 7:32 AM Nikita Popov  wrote:

> On Thu, Nov 18, 2021 at 2:07 PM Patrick ALLAERT 
> wrote:
>
> > Le mer. 17 nov. 2021 à 13:30, Christoph M. Becker  a
> > écrit :
> > > Right.  An alternative might be to let users report security issues to
> > > the security mailing list, where, if the issue turns out not to be a
> > > security issue, the reporter could still be asked to submit a GH issue
> > > about the bug.  In that case it might be useful to add more devs to the
> > > security mailing list.
> >
> > I was thinking about the same. Can't we work with security issues with
> > mailing list *only*?
> > It doesn't feel optimal to keep bugs.php.net active for just security
> > ones.
> > I miss seeing the motivation for it.
> >
>
> The problem with the security mailing list is that it's ephemeral --
> someone new can't look at past discussions before they were subscribed.
> Additionally, it's not possible to make the issue and the whole
> conversation around it public after the issue has been fixed.
>

With Laminas, we use an email alias to allow researchers to report to us.
We then post the full report as a security issue on GitHub - it's a feature
they rolled out late 2019/early 2020 that restricts visibility to
maintainers initially, but allows inviting others to collaborate (we invite
the reporter immediately, for instance). It also creates a private branch
for collaboration. When the patch has been merged, you can mark the issue
public.

If the plan is to move to GH anyways, this could solve security reporting.


> Regards,
> Nikita
>

Re: [PHP-DEV] Re: [RFC] Migrating to GitHub issues

[Nikita Popov]

On Thu, Nov 18, 2021 at 2:07 PM Patrick ALLAERT 
wrote:

> Le mer. 17 nov. 2021 à 13:30, Christoph M. Becker  a
> écrit :
> > Right.  An alternative might be to let users report security issues to
> > the security mailing list, where, if the issue turns out not to be a
> > security issue, the reporter could still be asked to submit a GH issue
> > about the bug.  In that case it might be useful to add more devs to the
> > security mailing list.
>
> I was thinking about the same. Can't we work with security issues with
> mailing list *only*?
> It doesn't feel optimal to keep bugs.php.net active for just security
> ones.
> I miss seeing the motivation for it.
>

The problem with the security mailing list is that it's ephemeral --
someone new can't look at past discussions before they were subscribed.
Additionally, it's not possible to make the issue and the whole
conversation around it public after the issue has been fixed.

Regards,
Nikita

Re: [PHP-DEV] Re: [RFC] Migrating to GitHub issues

[Patrick ALLAERT]

Le mer. 17 nov. 2021 à 13:30, Christoph M. Becker  a écrit :
> Right.  An alternative might be to let users report security issues to
> the security mailing list, where, if the issue turns out not to be a
> security issue, the reporter could still be asked to submit a GH issue
> about the bug.  In that case it might be useful to add more devs to the
> security mailing list.

I was thinking about the same. Can't we work with security issues with
mailing list *only*?
It doesn't feel optimal to keep bugs.php.net active for just security ones.
I miss seeing the motivation for it.

Patrick

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] PHP 7.3.33 Released!

[Christoph M. Becker]

The PHP development team announces the immediate availability of PHP
7.3.33.  This is a security release fixing CVE-2021-21707.

All PHP 7.3 users are encouraged to upgrade to this version.

For source downloads of PHP 7.3.33 please visit our downloads page.
Windows binaries can be found on the PHP for Windows site.
The list of changes is recorded in the ChangeLog.


Release Announcement: 
Downloads:
Windows downloads:
Changelog:

Many thanks to all the contributors and supporters!


Stanislav Malyshev, Christoph M. Becker


php-7.3.33.tar.bz2
SHA256 hash:
f412487d7d953437e7978a0d7b6ec99bf4a85cf3378014438a8577b89535451a
PGP signature:
-BEGIN PGP SIGNATURE-

iQJABAABCAAqFiEEy69p8XOg/qS1N/Rw1myVkxGLzLYFAmGTlBwMHGNtYkBwaHAu
bmV0AAoJENZslZMRi8y2cUUP/1JH/wLffG2sF9zhyF+L3RwZEmQL3dc1/y6VaAal
+7qcTX4xp6LQ/e9QZ0GKh9gvoLoVt0rj84SF8Tj+jSCpwXDH0AYJnYtC1U7IL7AH
MUqzGkj8M4/fXbNSb+L5FLFUTvrqzqrxV0L+/+PzFLOnK164RNbI1KITAvlrhDka
jQbigOIiWB2IKYGlVvpSnoOz2fZ1qZDa8agdkNhQa4swfINIpqcbHQHoNquEKt2J
W8QJEWApW1DAziqCZBy4qdjmZ1jEm0/m4UtDFAzxhwseXUgXa3EGz2sr2DWkQ5do
CVlU9xE5om5RssZu24vGPu4skobPzUg8zQh/ln9YkYKG7zE/8ahbv5q+zuR4wIfK
7X0jHy+ezlJ4oEwbmVJnrpOpiTCUo6WR02DJL6Q7s+N2LtNKXkn5KmSZhjEWDHMf
0GUhLjeSyrH3ad4HM6AO+Y5fXt+q0X6In5uC0pJuCWtjO9imeFD02sPcH3u96zgB
9G8sTWfsg6dHAVM4SHsr7D3wLalBLC5oo/8VUDKWclFI8OwaPt5qj9CMdxQBb2km
Sq9bfMq9WZpD7HPi3vI1/BpYke3DdIHLEElP978CchRPpL0iHV+XSWIRs4gLVIp6
OfVK+/YeSbklA7ZHrDzgpnot8jNoKwGOSQJllTSDoiv5Nf/U0oY2lVjVf5Tzw+XX
1qHZ
=wEgI
-END PGP SIGNATURE-


php-7.3.33.tar.gz
SHA256 hash:
9a369c32c6f52036b0a890f290327f148a1904ee66aa56e2c9a7546da6525ec8
PGP signature:
-BEGIN PGP SIGNATURE-

iQJABAABCAAqFiEEy69p8XOg/qS1N/Rw1myVkxGLzLYFAmGTlBwMHGNtYkBwaHAu
bmV0AAoJENZslZMRi8y2XF4P/0TIQTJwQ0TD76Jl52lBu1B4wk2zN2BkPpY3pUJO
8h/B071IcuOMXSBGvoKq3S4Exb8BckffLrqvMeGF6soFqkjMIKvj/tNd+4WhU1uO
8THTqMbDGOK2FnrkNxSGKYDuceh0ssByp1xAI3aj0d5lfu6y7wq/LTtA89iNqdTT
hRIEyztNqB9jgp2mHSssMULE+XCKHJvbskqbKvO/E9XC7AY/gkXoUsJTRpae1c8K
L1S/+Tjq1UkXqTLc8RjQ1JFkyt75BV44tKsiyaiQQT0kppIbdl1t5MazOsUzARPH
fnLFv3IEv1aJiYBIbo/tnfkf+poCKfTRGlVLap7kX2IhB+39+XrsfvRk2gdXHPag
kS8T5PxJyMf2w7B7A8KDbcFV/F8c7EjIfPuGb3Ezeq51jddki+6l5a4ACIvs78iv
TzObtZErT3Ne/1e4IWcGR9pdRL9oRDtbTaN5wnnalGtIkFkrzBddtvj7AjEmY+DG
kjosviM2TZ5cUHXVEnpsYJ3iOmSuVfYx6+5EmHcQTsvSWawdJwgWl0jHUD4eS6U6
rWetcVsXw7S8mVU284hvn+diJxPWCD+h04/nXcTy07sVmjP9FYBv/LYrPp+0T5az
R/8t105Y2OdVccBBRPbkxQA6LLBkh5WXLbmv71+Ly0r9GXX3rizAo/Kk9S6Saswe
C2nu
=oRdq
-END PGP SIGNATURE-


php-7.3.33.tar.xz
SHA256 hash:
166eaccde933381da9516a2b70ad0f447d7cec4b603d07b9a916032b215b90cc
PGP signature:
-BEGIN PGP SIGNATURE-

iQJABAABCAAqFiEEy69p8XOg/qS1N/Rw1myVkxGLzLYFAmGTlBwMHGNtYkBwaHAu
bmV0AAoJENZslZMRi8y29mIP/RhFuC5p9/c2TdEdN8sxqmLuThRr+p0cgHhWaR0m
dNhX1QKcpLbLLWEw758W4V7PsM62uSuxrWSnkLl4bmvI+qz4qNtj8hPYNC/tzt+P
ZMSuK9B3tCSW2LJziERCrTkLRo8pS9HnQv3NlpaJJFVdjyOshsLj4eyTCpNzB1wD
/DUzsT4znIxH5E07xvW0bp63yixVSZjE1/ssxt9ti46L4RxQJZJnYBIb4LKBIz42
qbCETgbD1wof6D/1z3GmeV+o+yTazts3Ha180jFEbN26wM9b54UJkjuI6ieX5gRd
jAumSoi+kO7gKGTlDq/LKPkAXfYKw2Az4vrEp77fhlcM4sXh41ShPkBQROzRUzAl
Jw3XKCuCwVwFm5lEyVu5Xnpo4u4YNNNJIacw8GlH7FnVkVpGbdjljKFvHGSZyU3t
rksQ47hztxPeaP77vwERa+74XrMYfNK9sWni83Pq4eve/4bbBKGoimoFutgpEwNt
4gfbVb0tKD5nMal2Ib9zIXYL0uOGRyR5AkQaldhRbsrDYF9jUcWEDAvYq73esnmD
0OLqvtNVxP3dt1B4Xee9WGKS5Nha0w8Fx5GzYrJBaSLZi+NdW2PTPebVCqJ2XrLN
mICc8sybkxr793h6cIXx0U/PexuhNn3ZH2kPKbhBmE0ynLYZygGVKwgjm0hSEdI4
w89Q
=WY2Z
-END PGP SIGNATURE-

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Proposal: &$result_code=null parameter in shell_exec()

[Christoph M. Becker]

On 18.11.2021 at 09:48, Hans Henrik Bergan wrote:

> while we're on the topic of shell_exec(), does anyone happen to know why
> shell_exec() pipes in *text mode*/binary-corruption-mode on windows?

I guess that is for historic reasons, where CRLF vs. LF really mattered
on Windows, and it's more common to get textual results with that
function.  There has been an RFC part[1] to change that, but it was
rejected.

[1] 

--
Christoph

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Proposal: &$result_code=null parameter in shell_exec()

[Luca Petrucci via internals]

On Thu, Nov 18, 2021 at 08:19:36AM +, Kamil Tekiela wrote:
> Hi Luca,
> 
> How will this change be reflected in its alias, the backtick operator? If
> the plan is to change the signature of shell_exec() then the backtick
> operator will not behave identically anymore. Am I correct?
> 
> Regards,
> Kamil
Hi,
PHP code that use the backtick operator or shell_exec() will behave identically.
The reason is that when omitting the optional parameter $return_code, the
function call shell_exec("command", null) is executed, which will
execute the "command" and return its output just like it does right now.

Thanks,
Luca

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Proposal: &$result_code=null parameter in shell_exec()

[Nikita Popov]

On Thu, Nov 18, 2021 at 8:47 AM Luca Petrucci via internals <
internals@lists.php.net> wrote:

> Hi internals,
>
> This is a proposal to add an optional parameter &$result_code = null to
> the shell_exec() function.
>
> For clarity, the current signature is
> shell_exec(string $command): string|false|null
> The proposed signature is
> shell_exec(string $command, int &$result_code = null): string|false|null
>
> If present, the result_code parameter is set to the exit code of the
> command, as it is in exec() and system().
>
> This feature request was also posted by another user on
> https://bugs.php.net/bug.php?id=81493
> I have a draft pull request at https://github.com/php/php-src/pull/7663
>
> Thoughts?
>
> Thanks,
> Luca
>

This looks like a reasonable addition to me. Between shell_exec(),
system(), passthru() and exec(), shell_exec() is the only function that
doesn't currently accept a $result_code parameter, so including it makes
sense for consistency.

Regards,
Nikita

Re: [PHP-DEV] Proposal: &$result_code=null parameter in shell_exec()

[Hans Henrik Bergan]

> then the backtick operator will not behave identically anymore. Am I
correct?

yeah kindof-correct, the backtick operator would then behave identically to
giving shell_exec() only 1 argument, or null as the 2nd argument
(btw i'm the guy that made the linked bugs.php.net feature request)

while we're on the topic of shell_exec(), does anyone happen to know why
shell_exec() pipes in *text mode*/binary-corruption-mode on windows?


On Thu, 18 Nov 2021 at 09:19, Kamil Tekiela  wrote:

> Hi Luca,
>
> How will this change be reflected in its alias, the backtick operator? If
> the plan is to change the signature of shell_exec() then the backtick
> operator will not behave identically anymore. Am I correct?
>
> Regards,
> Kamil
>

Re: [PHP-DEV] Proposal: &$result_code=null parameter in shell_exec()

[Kamil Tekiela]

Hi Luca,

How will this change be reflected in its alias, the backtick operator? If
the plan is to change the signature of shell_exec() then the backtick
operator will not behave identically anymore. Am I correct?

Regards,
Kamil