# env vars in HEAD/proc_open() issue?

- Thread: https://externals.io/message/39459
- Original archive: https://news-web.php.net/php.internals/39459
- Started by Steph Fox on 2008-07-30T13:01:28+00:00
- Messages: 5
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #39459 — Steph Fox — 2008-07-30T13:01:28+00:00

URL: https://externals.io/message/39459#39459

Hi all,

While merging ext/phar to HEAD, I found that environmental variables set in 
tests using the --ENV-- section fail to make it as far as the SAPI. Same 
with any other env var setting (e.g. my new '-x' parameter to run-tests.php 
fails too).

Over 100 'frontcontroller' and similar tests in phar fail in HEAD due to 
this (at least, I _hope_ just due to this!), so reproducing the problem is 
easy enough. I'd report it as a bug if I knew roughly where the problem lay, 
but it could be down to any of several culprits. That said, everything seems 
to be working right up to the point where `proc_open()` is called in 
system_with_timeout().

Can anyone on a different platform please confirm/give further clues?

Thanks,

- Steph

---

## #39461 — Hannes Magnusson — 2008-07-30T14:05:22+00:00

URL: https://externals.io/message/39459#39461 · In reply to: #39459

> Hi all,
>
> While merging ext/phar to HEAD, I found that environmental variables set in
> tests using the --ENV-- section fail to make it as far as the SAPI. Same
> with any other env var setting (e.g. my new '-x' parameter to run-tests.php
> fails too).

http://news.php.net/php.qa/64378

-Hannes

---

## #39464 — johannes@schlueters.de — 2008-07-30T14:14:02+00:00

URL: https://externals.io/message/39459#39464 · In reply to: #39459

Hi,


> While merging ext/phar to HEAD, I found that environmental variables set in 
> tests using the --ENV-- section fail to make it as far as the SAPI. Same 
> with any other env var setting (e.g. my new '-x' parameter to run-tests.php 
> fails too).
[...]
> Can anyone on a different platform please confirm/give further clues?

This also affects many other tests, like MySQL ones (see recent posting
from Ulf on qa@)

The issue is that there's a mix-up between our internal encoding
(utf-16) and the outside one. I don't know if there's a good way to get
the shell encoding to be used when converting to UTF-16 or if we should
use [script|runtime|filesystem|output|fallback|stream]_encoding - For me
all of them look wrong.

johannes

---

## #39469 — Steph Fox — 2008-07-30T15:51:22+00:00

URL: https://externals.io/message/39459#39469 · In reply to: #39464

Hey Johannes,

> The issue is that there's a mix-up between our internal encoding
> (utf-16) and the outside one.

That sounds normal :)

 I don't know if there's a good way to get
> the shell encoding to be used when converting to UTF-16 or if we should
> use [script|runtime|filesystem|output|fallback|stream]_encoding - For me
> all of them look wrong.

I have it working here now, but whether that's just because the test suite 
script's set to ISO-8859-1/UTF-8 I don't know...

- Steph

---

## #39485 — Steph Fox — 2008-07-30T20:22:16+00:00

URL: https://externals.io/message/39459#39485 · In reply to: #39469

Hi again,

> I have it working here now, but whether that's just because the test suite 
> script's set to ISO-8859-1/UTF-8 I don't know...

Patch attached in case anyone wants to mess about with it (nb 'ware DOS). 
It's nothing like commit-able, I was just fiddling, since having a third of 
our tests failing in HEAD poses a major problem when trying to maintain 
cross-version compatibility.

I found a problem with running zend_hash_find() on the env vars resulting 
from this patch. I think this is probably because the returned keys are 
unicode but the data is binary?

Outside of that issue, which *might* not be related anyway, 'it works on my 
box'.

- Steph