Bug #73716 [NEW]: Setting internal_encoding to value different from console CP corrupts console

From: Date: Sun, 11 Dec 2016 21:01:11 +0000
Subject: Bug #73716 [NEW]: Setting internal_encoding to value different from console CP corrupts console
Groups: php.bugs 
Request: Send a blank email to php-bugs+get-205916@lists.php.net to get a copy of this message 
From:             anrdaemon at freemail dot ru
Operating system: Windows
PHP version:      7.1.0
Package:          Output Control
Bug Type:         Bug
Bug description:Setting internal_encoding to value different from console CP corrupts console

Description:
------------
When internal_encoding is set (directly, say, internal_encoding=UTF-8,
or indirectly through default_charset) to a value different than the
current console charset, PHP will change console charset to that value
when executing script, leading to visual corruption of the console
buffer.

This may not look like much of a problem, since it will try to revert
the change before ecript ends, but two moments remain:
1. If startup error occured (f.e. extension not found), console CP will
not be restored.
2. While script works, console will remain in corrupted state.
3. This is RATHER surprising behavior, especially when you have both
input_encoding and output_encoding set to expected (and desired)
values.

For my example, I have russian Windows with default console charset
being CP866.
I set the settings for PHP CLI as follows:

default_mimetype = "text/plain" ; superfluous for CLI, but still
default_charset = "CP866" ; -- // --
input_encoding = "CP866" ; Presume I gonna read console input directly.
output_encoding = "CP866" ; I want program messages to be readable.

Then I have common shared configuration that sets

internal_encoding = "UTF-8"

...since I'm not stupid and prefer to work with data from different
sources with least possible chances for corruption.

Boom! Console corruption the moment I try this config with newly
installed PHP 7.1. Since half the extensions can't be loaded.
Yes, a fast run of "chcp" to realize it is turned into CP65001 AKA UTF-8
and a run of "chcp 866" to quickly put it into place, but that's me. I
know what I'm looking at.


-- 
Edit bug report at https://bugs.php.net/bug.php?id=73716&edit=1
-- 
Try a snapshot (PHP 5.4):   https://bugs.php.net/fix.php?id=73716&r=trysnapshot54
Try a snapshot (PHP 5.5):   https://bugs.php.net/fix.php?id=73716&r=trysnapshot55
Try a snapshot (trunk):     https://bugs.php.net/fix.php?id=73716&r=trysnapshottrunk
Fixed in SVN:               https://bugs.php.net/fix.php?id=73716&r=fixed
Fixed in release:           https://bugs.php.net/fix.php?id=73716&r=alreadyfixed
Need backtrace:             https://bugs.php.net/fix.php?id=73716&r=needtrace
Need Reproduce Script:      https://bugs.php.net/fix.php?id=73716&r=needscript
Try newer version:          https://bugs.php.net/fix.php?id=73716&r=oldversion
Not developer issue:        https://bugs.php.net/fix.php?id=73716&r=support
Expected behavior:          https://bugs.php.net/fix.php?id=73716&r=notwrong
Not enough info:            https://bugs.php.net/fix.php?id=73716&r=notenoughinfo
Submitted twice:            https://bugs.php.net/fix.php?id=73716&r=submittedtwice
register_globals:           https://bugs.php.net/fix.php?id=73716&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=73716&r=php4
Daylight Savings:           https://bugs.php.net/fix.php?id=73716&r=dst
IIS Stability:              https://bugs.php.net/fix.php?id=73716&r=isapi
Install GNU Sed:            https://bugs.php.net/fix.php?id=73716&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=73716&r=float
No Zend Extensions:         https://bugs.php.net/fix.php?id=73716&r=nozend
MySQL Configuration Error:  https://bugs.php.net/fix.php?id=73716&r=mysqlcfg

Thread (23 messages)

« previous php.bugs (#205916) next »