You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

1430 lines
38 KiB

12 years ago
8 years ago
23 years ago
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
10 years ago
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
10 years ago
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
10 years ago
23 years ago
19 years ago
19 years ago
19 years ago
19 years ago
19 years ago
19 years ago
24 years ago
19 years ago
19 years ago
19 years ago
19 years ago
19 years ago
19 years ago
19 years ago
19 years ago
23 years ago
19 years ago
23 years ago
19 years ago
19 years ago
19 years ago
23 years ago
19 years ago
19 years ago
19 years ago
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
10 years ago
8 years ago
20 years ago
20 years ago
20 years ago
20 years ago
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
10 years ago
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
10 years ago
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
10 years ago
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
10 years ago
24 years ago
24 years ago
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
10 years ago
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
10 years ago
  1. /*
  2. +----------------------------------------------------------------------+
  3. | PHP Version 7 |
  4. +----------------------------------------------------------------------+
  5. | Copyright (c) 1997-2018 The PHP Group |
  6. +----------------------------------------------------------------------+
  7. | This source file is subject to version 3.01 of the PHP license, |
  8. | that is bundled with this package in the file LICENSE, and is |
  9. | available through the world-wide-web at the following url: |
  10. | http://www.php.net/license/3_01.txt |
  11. | If you did not receive a copy of the PHP license and are unable to |
  12. | obtain it through the world-wide-web, please send a note to |
  13. | license@php.net so we can mail you a copy immediately. |
  14. +----------------------------------------------------------------------+
  15. | Author: Edin Kadribasic <edink@php.net> |
  16. | Marcus Boerger <helly@php.net> |
  17. | Johannes Schlueter <johannes@php.net> |
  18. | Parts based on CGI SAPI Module by |
  19. | Rasmus Lerdorf, Stig Bakken and Zeev Suraski |
  20. +----------------------------------------------------------------------+
  21. */
  22. /* $Id$ */
  23. #include "php.h"
  24. #include "php_globals.h"
  25. #include "php_variables.h"
  26. #include "zend_hash.h"
  27. #include "zend_modules.h"
  28. #include "zend_interfaces.h"
  29. #include "ext/reflection/php_reflection.h"
  30. #include "SAPI.h"
  31. #include <stdio.h>
  32. #include "php.h"
  33. #ifdef PHP_WIN32
  34. #include "win32/time.h"
  35. #include "win32/signal.h"
  36. #include <process.h>
  37. #include <shellapi.h>
  38. #endif
  39. #if HAVE_SYS_TIME_H
  40. #include <sys/time.h>
  41. #endif
  42. #if HAVE_UNISTD_H
  43. #include <unistd.h>
  44. #endif
  45. #if HAVE_SIGNAL_H
  46. #include <signal.h>
  47. #endif
  48. #if HAVE_SETLOCALE
  49. #include <locale.h>
  50. #endif
  51. #include "zend.h"
  52. #include "zend_extensions.h"
  53. #include "php_ini.h"
  54. #include "php_globals.h"
  55. #include "php_main.h"
  56. #include "fopen_wrappers.h"
  57. #include "ext/standard/php_standard.h"
  58. #include "cli.h"
  59. #ifdef PHP_WIN32
  60. #include <io.h>
  61. #include <fcntl.h>
  62. #include "win32/php_registry.h"
  63. #endif
  64. #if HAVE_SIGNAL_H
  65. #include <signal.h>
  66. #endif
  67. #ifdef __riscos__
  68. #include <unixlib/local.h>
  69. #endif
  70. #include "zend_compile.h"
  71. #include "zend_execute.h"
  72. #include "zend_highlight.h"
  73. #include "zend_exceptions.h"
  74. #include "php_getopt.h"
  75. #ifndef PHP_CLI_WIN32_NO_CONSOLE
  76. #include "php_cli_server.h"
  77. #endif
  78. #include "ps_title.h"
  79. #include "php_cli_process_title.h"
  80. #ifndef PHP_WIN32
  81. # define php_select(m, r, w, e, t) select(m, r, w, e, t)
  82. #else
  83. # include "win32/select.h"
  84. #endif
  85. #if defined(PHP_WIN32) && defined(HAVE_OPENSSL)
  86. # include "openssl/applink.c"
  87. #endif
  88. PHPAPI extern char *php_ini_opened_path;
  89. PHPAPI extern char *php_ini_scanned_path;
  90. PHPAPI extern char *php_ini_scanned_files;
  91. #if defined(PHP_WIN32)
  92. #if defined(ZTS)
  93. ZEND_TSRMLS_CACHE_DEFINE()
  94. #endif
  95. static DWORD orig_cp = 0;
  96. #endif
  97. #ifndef O_BINARY
  98. #define O_BINARY 0
  99. #endif
  100. #define PHP_MODE_STANDARD 1
  101. #define PHP_MODE_HIGHLIGHT 2
  102. #define PHP_MODE_LINT 4
  103. #define PHP_MODE_STRIP 5
  104. #define PHP_MODE_CLI_DIRECT 6
  105. #define PHP_MODE_PROCESS_STDIN 7
  106. #define PHP_MODE_REFLECTION_FUNCTION 8
  107. #define PHP_MODE_REFLECTION_CLASS 9
  108. #define PHP_MODE_REFLECTION_EXTENSION 10
  109. #define PHP_MODE_REFLECTION_EXT_INFO 11
  110. #define PHP_MODE_REFLECTION_ZEND_EXTENSION 12
  111. #define PHP_MODE_SHOW_INI_CONFIG 13
  112. cli_shell_callbacks_t cli_shell_callbacks = { NULL, NULL, NULL };
  113. PHP_CLI_API cli_shell_callbacks_t *php_cli_get_shell_callbacks()
  114. {
  115. return &cli_shell_callbacks;
  116. }
  117. const char HARDCODED_INI[] =
  118. "html_errors=0\n"
  119. "register_argc_argv=1\n"
  120. "implicit_flush=1\n"
  121. "output_buffering=0\n"
  122. "max_execution_time=0\n"
  123. "max_input_time=-1\n\0";
  124. const opt_struct OPTIONS[] = {
  125. {'a', 0, "interactive"},
  126. {'B', 1, "process-begin"},
  127. {'C', 0, "no-chdir"}, /* for compatibility with CGI (do not chdir to script directory) */
  128. {'c', 1, "php-ini"},
  129. {'d', 1, "define"},
  130. {'E', 1, "process-end"},
  131. {'e', 0, "profile-info"},
  132. {'F', 1, "process-file"},
  133. {'f', 1, "file"},
  134. {'h', 0, "help"},
  135. {'i', 0, "info"},
  136. {'l', 0, "syntax-check"},
  137. {'m', 0, "modules"},
  138. {'n', 0, "no-php-ini"},
  139. {'q', 0, "no-header"}, /* for compatibility with CGI (do not generate HTTP headers) */
  140. {'R', 1, "process-code"},
  141. {'H', 0, "hide-args"},
  142. {'r', 1, "run"},
  143. {'s', 0, "syntax-highlight"},
  144. {'s', 0, "syntax-highlighting"},
  145. {'S', 1, "server"},
  146. {'t', 1, "docroot"},
  147. {'w', 0, "strip"},
  148. {'?', 0, "usage"},/* help alias (both '?' and 'usage') */
  149. {'v', 0, "version"},
  150. {'z', 1, "zend-extension"},
  151. {10, 1, "rf"},
  152. {10, 1, "rfunction"},
  153. {11, 1, "rc"},
  154. {11, 1, "rclass"},
  155. {12, 1, "re"},
  156. {12, 1, "rextension"},
  157. {13, 1, "rz"},
  158. {13, 1, "rzendextension"},
  159. {14, 1, "ri"},
  160. {14, 1, "rextinfo"},
  161. {15, 0, "ini"},
  162. {'-', 0, NULL} /* end of args */
  163. };
  164. static int print_module_info(zval *element) /* {{{ */
  165. {
  166. zend_module_entry *module = (zend_module_entry*)Z_PTR_P(element);
  167. php_printf("%s\n", module->name);
  168. return ZEND_HASH_APPLY_KEEP;
  169. }
  170. /* }}} */
  171. static int module_name_cmp(const void *a, const void *b) /* {{{ */
  172. {
  173. Bucket *f = (Bucket *) a;
  174. Bucket *s = (Bucket *) b;
  175. return strcasecmp(((zend_module_entry *)Z_PTR(f->val))->name,
  176. ((zend_module_entry *)Z_PTR(s->val))->name);
  177. }
  178. /* }}} */
  179. static void print_modules(void) /* {{{ */
  180. {
  181. HashTable sorted_registry;
  182. zend_hash_init(&sorted_registry, 50, NULL, NULL, 0);
  183. zend_hash_copy(&sorted_registry, &module_registry, NULL);
  184. zend_hash_sort(&sorted_registry, module_name_cmp, 0);
  185. zend_hash_apply(&sorted_registry, print_module_info);
  186. zend_hash_destroy(&sorted_registry);
  187. }
  188. /* }}} */
  189. static int print_extension_info(zend_extension *ext, void *arg) /* {{{ */
  190. {
  191. php_printf("%s\n", ext->name);
  192. return ZEND_HASH_APPLY_KEEP;
  193. }
  194. /* }}} */
  195. static int extension_name_cmp(const zend_llist_element **f, const zend_llist_element **s) /* {{{ */
  196. {
  197. zend_extension *fe = (zend_extension*)(*f)->data;
  198. zend_extension *se = (zend_extension*)(*s)->data;
  199. return strcmp(fe->name, se->name);
  200. }
  201. /* }}} */
  202. static void print_extensions(void) /* {{{ */
  203. {
  204. zend_llist sorted_exts;
  205. zend_llist_copy(&sorted_exts, &zend_extensions);
  206. sorted_exts.dtor = NULL;
  207. zend_llist_sort(&sorted_exts, extension_name_cmp);
  208. zend_llist_apply(&sorted_exts, (llist_apply_func_t) print_extension_info);
  209. zend_llist_destroy(&sorted_exts);
  210. }
  211. /* }}} */
  212. #ifndef STDOUT_FILENO
  213. #define STDOUT_FILENO 1
  214. #endif
  215. static inline int sapi_cli_select(int fd)
  216. {
  217. fd_set wfd, dfd;
  218. struct timeval tv;
  219. int ret;
  220. FD_ZERO(&wfd);
  221. FD_ZERO(&dfd);
  222. PHP_SAFE_FD_SET(fd, &wfd);
  223. tv.tv_sec = (long)FG(default_socket_timeout);
  224. tv.tv_usec = 0;
  225. ret = php_select(fd+1, &dfd, &wfd, &dfd, &tv);
  226. return ret != -1;
  227. }
  228. PHP_CLI_API size_t sapi_cli_single_write(const char *str, size_t str_length) /* {{{ */
  229. {
  230. #ifdef PHP_WRITE_STDOUT
  231. zend_long ret;
  232. #else
  233. size_t ret;
  234. #endif
  235. if (cli_shell_callbacks.cli_shell_write) {
  236. cli_shell_callbacks.cli_shell_write(str, str_length);
  237. }
  238. #ifdef PHP_WRITE_STDOUT
  239. do {
  240. ret = write(STDOUT_FILENO, str, str_length);
  241. } while (ret <= 0 && errno == EAGAIN && sapi_cli_select(STDOUT_FILENO));
  242. if (ret <= 0) {
  243. return 0;
  244. }
  245. return ret;
  246. #else
  247. ret = fwrite(str, 1, MIN(str_length, 16384), stdout);
  248. return ret;
  249. #endif
  250. }
  251. /* }}} */
  252. static size_t sapi_cli_ub_write(const char *str, size_t str_length) /* {{{ */
  253. {
  254. const char *ptr = str;
  255. size_t remaining = str_length;
  256. size_t ret;
  257. if (!str_length) {
  258. return 0;
  259. }
  260. if (cli_shell_callbacks.cli_shell_ub_write) {
  261. size_t ub_wrote;
  262. ub_wrote = cli_shell_callbacks.cli_shell_ub_write(str, str_length);
  263. if (ub_wrote != (size_t) -1) {
  264. return ub_wrote;
  265. }
  266. }
  267. while (remaining > 0)
  268. {
  269. ret = sapi_cli_single_write(ptr, remaining);
  270. if (!ret) {
  271. #ifndef PHP_CLI_WIN32_NO_CONSOLE
  272. php_handle_aborted_connection();
  273. #endif
  274. break;
  275. }
  276. ptr += ret;
  277. remaining -= ret;
  278. }
  279. return (ptr - str);
  280. }
  281. /* }}} */
  282. static void sapi_cli_flush(void *server_context) /* {{{ */
  283. {
  284. /* Ignore EBADF here, it's caused by the fact that STDIN/STDOUT/STDERR streams
  285. * are/could be closed before fflush() is called.
  286. */
  287. if (fflush(stdout)==EOF && errno!=EBADF) {
  288. #ifndef PHP_CLI_WIN32_NO_CONSOLE
  289. php_handle_aborted_connection();
  290. #endif
  291. }
  292. }
  293. /* }}} */
  294. static char *php_self = "";
  295. static char *script_filename = "";
  296. static void sapi_cli_register_variables(zval *track_vars_array) /* {{{ */
  297. {
  298. size_t len;
  299. char *docroot = "";
  300. /* In CGI mode, we consider the environment to be a part of the server
  301. * variables
  302. */
  303. php_import_environment_variables(track_vars_array);
  304. /* Build the special-case PHP_SELF variable for the CLI version */
  305. len = strlen(php_self);
  306. if (sapi_module.input_filter(PARSE_SERVER, "PHP_SELF", &php_self, len, &len)) {
  307. php_register_variable("PHP_SELF", php_self, track_vars_array);
  308. }
  309. if (sapi_module.input_filter(PARSE_SERVER, "SCRIPT_NAME", &php_self, len, &len)) {
  310. php_register_variable("SCRIPT_NAME", php_self, track_vars_array);
  311. }
  312. /* filenames are empty for stdin */
  313. len = strlen(script_filename);
  314. if (sapi_module.input_filter(PARSE_SERVER, "SCRIPT_FILENAME", &script_filename, len, &len)) {
  315. php_register_variable("SCRIPT_FILENAME", script_filename, track_vars_array);
  316. }
  317. if (sapi_module.input_filter(PARSE_SERVER, "PATH_TRANSLATED", &script_filename, len, &len)) {
  318. php_register_variable("PATH_TRANSLATED", script_filename, track_vars_array);
  319. }
  320. /* just make it available */
  321. len = 0U;
  322. if (sapi_module.input_filter(PARSE_SERVER, "DOCUMENT_ROOT", &docroot, len, &len)) {
  323. php_register_variable("DOCUMENT_ROOT", docroot, track_vars_array);
  324. }
  325. }
  326. /* }}} */
  327. static void sapi_cli_log_message(char *message, int syslog_type_int) /* {{{ */
  328. {
  329. fprintf(stderr, "%s\n", message);
  330. #ifdef PHP_WIN32
  331. fflush(stderr);
  332. #endif
  333. }
  334. /* }}} */
  335. static int sapi_cli_deactivate(void) /* {{{ */
  336. {
  337. fflush(stdout);
  338. if(SG(request_info).argv0) {
  339. free(SG(request_info).argv0);
  340. SG(request_info).argv0 = NULL;
  341. }
  342. return SUCCESS;
  343. }
  344. /* }}} */
  345. static char* sapi_cli_read_cookies(void) /* {{{ */
  346. {
  347. return NULL;
  348. }
  349. /* }}} */
  350. static int sapi_cli_header_handler(sapi_header_struct *h, sapi_header_op_enum op, sapi_headers_struct *s) /* {{{ */
  351. {
  352. return 0;
  353. }
  354. /* }}} */
  355. static int sapi_cli_send_headers(sapi_headers_struct *sapi_headers) /* {{{ */
  356. {
  357. /* We do nothing here, this function is needed to prevent that the fallback
  358. * header handling is called. */
  359. return SAPI_HEADER_SENT_SUCCESSFULLY;
  360. }
  361. /* }}} */
  362. static void sapi_cli_send_header(sapi_header_struct *sapi_header, void *server_context) /* {{{ */
  363. {
  364. }
  365. /* }}} */
  366. static int php_cli_startup(sapi_module_struct *sapi_module) /* {{{ */
  367. {
  368. if (php_module_startup(sapi_module, NULL, 0)==FAILURE) {
  369. return FAILURE;
  370. }
  371. return SUCCESS;
  372. }
  373. /* }}} */
  374. /* {{{ sapi_cli_ini_defaults */
  375. /* overwriteable ini defaults must be set in sapi_cli_ini_defaults() */
  376. #define INI_DEFAULT(name,value)\
  377. ZVAL_NEW_STR(&tmp, zend_string_init(value, sizeof(value)-1, 1));\
  378. zend_hash_str_update(configuration_hash, name, sizeof(name)-1, &tmp);\
  379. static void sapi_cli_ini_defaults(HashTable *configuration_hash)
  380. {
  381. zval tmp;
  382. INI_DEFAULT("report_zend_debug", "0");
  383. INI_DEFAULT("display_errors", "1");
  384. }
  385. /* }}} */
  386. /* {{{ sapi_module_struct cli_sapi_module
  387. */
  388. static sapi_module_struct cli_sapi_module = {
  389. "cli", /* name */
  390. "Command Line Interface", /* pretty name */
  391. php_cli_startup, /* startup */
  392. php_module_shutdown_wrapper, /* shutdown */
  393. NULL, /* activate */
  394. sapi_cli_deactivate, /* deactivate */
  395. sapi_cli_ub_write, /* unbuffered write */
  396. sapi_cli_flush, /* flush */
  397. NULL, /* get uid */
  398. NULL, /* getenv */
  399. php_error, /* error handler */
  400. sapi_cli_header_handler, /* header handler */
  401. sapi_cli_send_headers, /* send headers handler */
  402. sapi_cli_send_header, /* send header handler */
  403. NULL, /* read POST data */
  404. sapi_cli_read_cookies, /* read Cookies */
  405. sapi_cli_register_variables, /* register server variables */
  406. sapi_cli_log_message, /* Log message */
  407. NULL, /* Get request time */
  408. NULL, /* Child terminate */
  409. STANDARD_SAPI_MODULE_PROPERTIES
  410. };
  411. /* }}} */
  412. /* {{{ arginfo ext/standard/dl.c */
  413. ZEND_BEGIN_ARG_INFO(arginfo_dl, 0)
  414. ZEND_ARG_INFO(0, extension_filename)
  415. ZEND_END_ARG_INFO()
  416. /* }}} */
  417. static const zend_function_entry additional_functions[] = {
  418. ZEND_FE(dl, arginfo_dl)
  419. PHP_FE(cli_set_process_title, arginfo_cli_set_process_title)
  420. PHP_FE(cli_get_process_title, arginfo_cli_get_process_title)
  421. PHP_FE_END
  422. };
  423. /* {{{ php_cli_usage
  424. */
  425. static void php_cli_usage(char *argv0)
  426. {
  427. char *prog;
  428. prog = strrchr(argv0, '/');
  429. if (prog) {
  430. prog++;
  431. } else {
  432. prog = "php";
  433. }
  434. printf( "Usage: %s [options] [-f] <file> [--] [args...]\n"
  435. " %s [options] -r <code> [--] [args...]\n"
  436. " %s [options] [-B <begin_code>] -R <code> [-E <end_code>] [--] [args...]\n"
  437. " %s [options] [-B <begin_code>] -F <file> [-E <end_code>] [--] [args...]\n"
  438. " %s [options] -S <addr>:<port> [-t docroot] [router]\n"
  439. " %s [options] -- [args...]\n"
  440. " %s [options] -a\n"
  441. "\n"
  442. #if (HAVE_LIBREADLINE || HAVE_LIBEDIT) && !defined(COMPILE_DL_READLINE)
  443. " -a Run as interactive shell\n"
  444. #else
  445. " -a Run interactively\n"
  446. #endif
  447. " -c <path>|<file> Look for php.ini file in this directory\n"
  448. " -n No configuration (ini) files will be used\n"
  449. " -d foo[=bar] Define INI entry foo with value 'bar'\n"
  450. " -e Generate extended information for debugger/profiler\n"
  451. " -f <file> Parse and execute <file>.\n"
  452. " -h This help\n"
  453. " -i PHP information\n"
  454. " -l Syntax check only (lint)\n"
  455. " -m Show compiled in modules\n"
  456. " -r <code> Run PHP <code> without using script tags <?..?>\n"
  457. " -B <begin_code> Run PHP <begin_code> before processing input lines\n"
  458. " -R <code> Run PHP <code> for every input line\n"
  459. " -F <file> Parse and execute <file> for every input line\n"
  460. " -E <end_code> Run PHP <end_code> after processing all input lines\n"
  461. " -H Hide any passed arguments from external tools.\n"
  462. " -S <addr>:<port> Run with built-in web server.\n"
  463. " -t <docroot> Specify document root <docroot> for built-in web server.\n"
  464. " -s Output HTML syntax highlighted source.\n"
  465. " -v Version number\n"
  466. " -w Output source with stripped comments and whitespace.\n"
  467. " -z <file> Load Zend extension <file>.\n"
  468. "\n"
  469. " args... Arguments passed to script. Use -- args when first argument\n"
  470. " starts with - or script is read from stdin\n"
  471. "\n"
  472. " --ini Show configuration file names\n"
  473. "\n"
  474. " --rf <name> Show information about function <name>.\n"
  475. " --rc <name> Show information about class <name>.\n"
  476. " --re <name> Show information about extension <name>.\n"
  477. " --rz <name> Show information about Zend extension <name>.\n"
  478. " --ri <name> Show configuration for extension <name>.\n"
  479. "\n"
  480. , prog, prog, prog, prog, prog, prog, prog);
  481. }
  482. /* }}} */
  483. static php_stream *s_in_process = NULL;
  484. static void cli_register_file_handles(void) /* {{{ */
  485. {
  486. php_stream *s_in, *s_out, *s_err;
  487. php_stream_context *sc_in=NULL, *sc_out=NULL, *sc_err=NULL;
  488. zend_constant ic, oc, ec;
  489. s_in = php_stream_open_wrapper_ex("php://stdin", "rb", 0, NULL, sc_in);
  490. s_out = php_stream_open_wrapper_ex("php://stdout", "wb", 0, NULL, sc_out);
  491. s_err = php_stream_open_wrapper_ex("php://stderr", "wb", 0, NULL, sc_err);
  492. if (s_in==NULL || s_out==NULL || s_err==NULL) {
  493. if (s_in) php_stream_close(s_in);
  494. if (s_out) php_stream_close(s_out);
  495. if (s_err) php_stream_close(s_err);
  496. return;
  497. }
  498. #if PHP_DEBUG
  499. /* do not close stdout and stderr */
  500. s_out->flags |= PHP_STREAM_FLAG_NO_CLOSE;
  501. s_err->flags |= PHP_STREAM_FLAG_NO_CLOSE;
  502. #endif
  503. s_in_process = s_in;
  504. php_stream_to_zval(s_in, &ic.value);
  505. php_stream_to_zval(s_out, &oc.value);
  506. php_stream_to_zval(s_err, &ec.value);
  507. ic.flags = CONST_CS;
  508. ic.name = zend_string_init("STDIN", sizeof("STDIN")-1, 1);
  509. ic.module_number = 0;
  510. zend_register_constant(&ic);
  511. oc.flags = CONST_CS;
  512. oc.name = zend_string_init("STDOUT", sizeof("STDOUT")-1, 1);
  513. oc.module_number = 0;
  514. zend_register_constant(&oc);
  515. ec.flags = CONST_CS;
  516. ec.name = zend_string_init("STDERR", sizeof("STDERR")-1, 1);
  517. ec.module_number = 0;
  518. zend_register_constant(&ec);
  519. }
  520. /* }}} */
  521. static const char *param_mode_conflict = "Either execute direct code, process stdin or use a file.\n";
  522. /* {{{ cli_seek_file_begin
  523. */
  524. static int cli_seek_file_begin(zend_file_handle *file_handle, char *script_file, int *lineno)
  525. {
  526. int c;
  527. *lineno = 1;
  528. file_handle->type = ZEND_HANDLE_FP;
  529. file_handle->opened_path = NULL;
  530. file_handle->free_filename = 0;
  531. if (!(file_handle->handle.fp = VCWD_FOPEN(script_file, "rb"))) {
  532. php_printf("Could not open input file: %s\n", script_file);
  533. return FAILURE;
  534. }
  535. file_handle->filename = script_file;
  536. /* #!php support */
  537. c = fgetc(file_handle->handle.fp);
  538. if (c == '#' && (c = fgetc(file_handle->handle.fp)) == '!') {
  539. while (c != '\n' && c != '\r' && c != EOF) {
  540. c = fgetc(file_handle->handle.fp); /* skip to end of line */
  541. }
  542. /* handle situations where line is terminated by \r\n */
  543. if (c == '\r') {
  544. if (fgetc(file_handle->handle.fp) != '\n') {
  545. zend_long pos = zend_ftell(file_handle->handle.fp);
  546. zend_fseek(file_handle->handle.fp, pos - 1, SEEK_SET);
  547. }
  548. }
  549. *lineno = 2;
  550. } else {
  551. rewind(file_handle->handle.fp);
  552. }
  553. return SUCCESS;
  554. }
  555. /* }}} */
  556. /*{{{ php_cli_win32_ctrl_handler */
  557. #if defined(PHP_WIN32) && !defined(PHP_CLI_WIN32_NO_CONSOLE)
  558. BOOL WINAPI php_cli_win32_ctrl_handler(DWORD sig)
  559. {
  560. (void)php_win32_cp_cli_do_restore(orig_cp);
  561. return FALSE;
  562. }
  563. #endif
  564. /*}}}*/
  565. static int do_cli(int argc, char **argv) /* {{{ */
  566. {
  567. int c;
  568. zend_file_handle file_handle;
  569. int behavior = PHP_MODE_STANDARD;
  570. char *reflection_what = NULL;
  571. volatile int request_started = 0;
  572. volatile int exit_status = 0;
  573. char *php_optarg = NULL, *orig_optarg = NULL;
  574. int php_optind = 1, orig_optind = 1;
  575. char *exec_direct=NULL, *exec_run=NULL, *exec_begin=NULL, *exec_end=NULL;
  576. char *arg_free=NULL, **arg_excp=&arg_free;
  577. char *script_file=NULL, *translated_path = NULL;
  578. int interactive=0;
  579. int lineno = 0;
  580. const char *param_error=NULL;
  581. int hide_argv = 0;
  582. zend_try {
  583. CG(in_compilation) = 0; /* not initialized but needed for several options */
  584. while ((c = php_getopt(argc, argv, OPTIONS, &php_optarg, &php_optind, 0, 2)) != -1) {
  585. switch (c) {
  586. case 'i': /* php info & quit */
  587. if (php_request_startup()==FAILURE) {
  588. goto err;
  589. }
  590. request_started = 1;
  591. php_print_info(0xFFFFFFFF);
  592. php_output_end_all();
  593. exit_status = (c == '?' && argc > 1 && !strchr(argv[1], c));
  594. goto out;
  595. case 'v': /* show php version & quit */
  596. php_printf("PHP %s (%s) (built: %s %s) ( %s)\nCopyright (c) 1997-2018 The PHP Group\n%s",
  597. PHP_VERSION, cli_sapi_module.name, __DATE__, __TIME__,
  598. #if ZTS
  599. "ZTS "
  600. #else
  601. "NTS "
  602. #endif
  603. #ifdef COMPILER
  604. COMPILER
  605. " "
  606. #endif
  607. #ifdef ARCHITECTURE
  608. ARCHITECTURE
  609. " "
  610. #endif
  611. #if ZEND_DEBUG
  612. "DEBUG "
  613. #endif
  614. #ifdef HAVE_GCOV
  615. "GCOV "
  616. #endif
  617. ,
  618. get_zend_version()
  619. );
  620. sapi_deactivate();
  621. goto out;
  622. case 'm': /* list compiled in modules */
  623. if (php_request_startup()==FAILURE) {
  624. goto err;
  625. }
  626. request_started = 1;
  627. php_printf("[PHP Modules]\n");
  628. print_modules();
  629. php_printf("\n[Zend Modules]\n");
  630. print_extensions();
  631. php_printf("\n");
  632. php_output_end_all();
  633. exit_status=0;
  634. goto out;
  635. default:
  636. break;
  637. }
  638. }
  639. /* Set some CLI defaults */
  640. SG(options) |= SAPI_OPTION_NO_CHDIR;
  641. php_optind = orig_optind;
  642. php_optarg = orig_optarg;
  643. while ((c = php_getopt(argc, argv, OPTIONS, &php_optarg, &php_optind, 0, 2)) != -1) {
  644. switch (c) {
  645. case 'a': /* interactive mode */
  646. if (!interactive) {
  647. if (behavior != PHP_MODE_STANDARD) {
  648. param_error = param_mode_conflict;
  649. break;
  650. }
  651. interactive=1;
  652. }
  653. break;
  654. case 'C': /* don't chdir to the script directory */
  655. /* This is default so NOP */
  656. break;
  657. case 'F':
  658. if (behavior == PHP_MODE_PROCESS_STDIN) {
  659. if (exec_run || script_file) {
  660. param_error = "You can use -R or -F only once.\n";
  661. break;
  662. }
  663. } else if (behavior != PHP_MODE_STANDARD) {
  664. param_error = param_mode_conflict;
  665. break;
  666. }
  667. behavior=PHP_MODE_PROCESS_STDIN;
  668. script_file = php_optarg;
  669. break;
  670. case 'f': /* parse file */
  671. if (behavior == PHP_MODE_CLI_DIRECT || behavior == PHP_MODE_PROCESS_STDIN) {
  672. param_error = param_mode_conflict;
  673. break;
  674. } else if (script_file) {
  675. param_error = "You can use -f only once.\n";
  676. break;
  677. }
  678. script_file = php_optarg;
  679. break;
  680. case 'l': /* syntax check mode */
  681. if (behavior != PHP_MODE_STANDARD) {
  682. break;
  683. }
  684. behavior=PHP_MODE_LINT;
  685. break;
  686. case 'q': /* do not generate HTTP headers */
  687. /* This is default so NOP */
  688. break;
  689. case 'r': /* run code from command line */
  690. if (behavior == PHP_MODE_CLI_DIRECT) {
  691. if (exec_direct || script_file) {
  692. param_error = "You can use -r only once.\n";
  693. break;
  694. }
  695. } else if (behavior != PHP_MODE_STANDARD || interactive) {
  696. param_error = param_mode_conflict;
  697. break;
  698. }
  699. behavior=PHP_MODE_CLI_DIRECT;
  700. exec_direct=php_optarg;
  701. break;
  702. case 'R':
  703. if (behavior == PHP_MODE_PROCESS_STDIN) {
  704. if (exec_run || script_file) {
  705. param_error = "You can use -R or -F only once.\n";
  706. break;
  707. }
  708. } else if (behavior != PHP_MODE_STANDARD) {
  709. param_error = param_mode_conflict;
  710. break;
  711. }
  712. behavior=PHP_MODE_PROCESS_STDIN;
  713. exec_run=php_optarg;
  714. break;
  715. case 'B':
  716. if (behavior == PHP_MODE_PROCESS_STDIN) {
  717. if (exec_begin) {
  718. param_error = "You can use -B only once.\n";
  719. break;
  720. }
  721. } else if (behavior != PHP_MODE_STANDARD || interactive) {
  722. param_error = param_mode_conflict;
  723. break;
  724. }
  725. behavior=PHP_MODE_PROCESS_STDIN;
  726. exec_begin=php_optarg;
  727. break;
  728. case 'E':
  729. if (behavior == PHP_MODE_PROCESS_STDIN) {
  730. if (exec_end) {
  731. param_error = "You can use -E only once.\n";
  732. break;
  733. }
  734. } else if (behavior != PHP_MODE_STANDARD || interactive) {
  735. param_error = param_mode_conflict;
  736. break;
  737. }
  738. behavior=PHP_MODE_PROCESS_STDIN;
  739. exec_end=php_optarg;
  740. break;
  741. case 's': /* generate highlighted HTML from source */
  742. if (behavior == PHP_MODE_CLI_DIRECT || behavior == PHP_MODE_PROCESS_STDIN) {
  743. param_error = "Source highlighting only works for files.\n";
  744. break;
  745. }
  746. behavior=PHP_MODE_HIGHLIGHT;
  747. break;
  748. case 'w':
  749. if (behavior == PHP_MODE_CLI_DIRECT || behavior == PHP_MODE_PROCESS_STDIN) {
  750. param_error = "Source stripping only works for files.\n";
  751. break;
  752. }
  753. behavior=PHP_MODE_STRIP;
  754. break;
  755. case 'z': /* load extension file */
  756. zend_load_extension(php_optarg);
  757. break;
  758. case 'H':
  759. hide_argv = 1;
  760. break;
  761. case 10:
  762. behavior=PHP_MODE_REFLECTION_FUNCTION;
  763. reflection_what = php_optarg;
  764. break;
  765. case 11:
  766. behavior=PHP_MODE_REFLECTION_CLASS;
  767. reflection_what = php_optarg;
  768. break;
  769. case 12:
  770. behavior=PHP_MODE_REFLECTION_EXTENSION;
  771. reflection_what = php_optarg;
  772. break;
  773. case 13:
  774. behavior=PHP_MODE_REFLECTION_ZEND_EXTENSION;
  775. reflection_what = php_optarg;
  776. break;
  777. case 14:
  778. behavior=PHP_MODE_REFLECTION_EXT_INFO;
  779. reflection_what = php_optarg;
  780. break;
  781. case 15:
  782. behavior = PHP_MODE_SHOW_INI_CONFIG;
  783. break;
  784. default:
  785. break;
  786. }
  787. }
  788. if (param_error) {
  789. PUTS(param_error);
  790. exit_status=1;
  791. goto err;
  792. }
  793. if (interactive) {
  794. #if (HAVE_LIBREADLINE || HAVE_LIBEDIT) && !defined(COMPILE_DL_READLINE)
  795. printf("Interactive shell\n\n");
  796. #else
  797. printf("Interactive mode enabled\n\n");
  798. #endif
  799. fflush(stdout);
  800. }
  801. /* only set script_file if not set already and not in direct mode and not at end of parameter list */
  802. if (argc > php_optind
  803. && !script_file
  804. && behavior!=PHP_MODE_CLI_DIRECT
  805. && behavior!=PHP_MODE_PROCESS_STDIN
  806. && strcmp(argv[php_optind-1],"--"))
  807. {
  808. script_file=argv[php_optind];
  809. php_optind++;
  810. }
  811. if (script_file) {
  812. if (cli_seek_file_begin(&file_handle, script_file, &lineno) != SUCCESS) {
  813. goto err;
  814. } else {
  815. char real_path[MAXPATHLEN];
  816. if (VCWD_REALPATH(script_file, real_path)) {
  817. translated_path = strdup(real_path);
  818. }
  819. script_filename = script_file;
  820. }
  821. } else {
  822. /* We could handle PHP_MODE_PROCESS_STDIN in a different manner */
  823. /* here but this would make things only more complicated. And it */
  824. /* is consitent with the way -R works where the stdin file handle*/
  825. /* is also accessible. */
  826. file_handle.filename = "-";
  827. file_handle.handle.fp = stdin;
  828. }
  829. file_handle.type = ZEND_HANDLE_FP;
  830. file_handle.opened_path = NULL;
  831. file_handle.free_filename = 0;
  832. php_self = (char*)file_handle.filename;
  833. /* before registering argv to module exchange the *new* argv[0] */
  834. /* we can achieve this without allocating more memory */
  835. SG(request_info).argc=argc-php_optind+1;
  836. arg_excp = argv+php_optind-1;
  837. arg_free = argv[php_optind-1];
  838. SG(request_info).path_translated = translated_path? translated_path: (char*)file_handle.filename;
  839. argv[php_optind-1] = (char*)file_handle.filename;
  840. SG(request_info).argv=argv+php_optind-1;
  841. if (php_request_startup()==FAILURE) {
  842. *arg_excp = arg_free;
  843. fclose(file_handle.handle.fp);
  844. PUTS("Could not startup.\n");
  845. goto err;
  846. }
  847. request_started = 1;
  848. CG(start_lineno) = lineno;
  849. *arg_excp = arg_free; /* reconstuct argv */
  850. if (hide_argv) {
  851. int i;
  852. for (i = 1; i < argc; i++) {
  853. memset(argv[i], 0, strlen(argv[i]));
  854. }
  855. }
  856. zend_is_auto_global_str(ZEND_STRL("_SERVER"));
  857. PG(during_request_startup) = 0;
  858. switch (behavior) {
  859. case PHP_MODE_STANDARD:
  860. if (strcmp(file_handle.filename, "-")) {
  861. cli_register_file_handles();
  862. }
  863. if (interactive && cli_shell_callbacks.cli_shell_run) {
  864. exit_status = cli_shell_callbacks.cli_shell_run();
  865. } else {
  866. php_execute_script(&file_handle);
  867. exit_status = EG(exit_status);
  868. }
  869. break;
  870. case PHP_MODE_LINT:
  871. exit_status = php_lint_script(&file_handle);
  872. if (exit_status==SUCCESS) {
  873. zend_printf("No syntax errors detected in %s\n", file_handle.filename);
  874. } else {
  875. zend_printf("Errors parsing %s\n", file_handle.filename);
  876. }
  877. break;
  878. case PHP_MODE_STRIP:
  879. if (open_file_for_scanning(&file_handle)==SUCCESS) {
  880. zend_strip();
  881. }
  882. goto out;
  883. break;
  884. case PHP_MODE_HIGHLIGHT:
  885. {
  886. zend_syntax_highlighter_ini syntax_highlighter_ini;
  887. if (open_file_for_scanning(&file_handle)==SUCCESS) {
  888. php_get_highlight_struct(&syntax_highlighter_ini);
  889. zend_highlight(&syntax_highlighter_ini);
  890. }
  891. goto out;
  892. }
  893. break;
  894. case PHP_MODE_CLI_DIRECT:
  895. cli_register_file_handles();
  896. if (zend_eval_string_ex(exec_direct, NULL, "Command line code", 1) == FAILURE) {
  897. exit_status=254;
  898. }
  899. break;
  900. case PHP_MODE_PROCESS_STDIN:
  901. {
  902. char *input;
  903. size_t len, index = 0;
  904. zval argn, argi;
  905. cli_register_file_handles();
  906. if (exec_begin && zend_eval_string_ex(exec_begin, NULL, "Command line begin code", 1) == FAILURE) {
  907. exit_status=254;
  908. }
  909. while (exit_status == SUCCESS && (input=php_stream_gets(s_in_process, NULL, 0)) != NULL) {
  910. len = strlen(input);
  911. while (len > 0 && len-- && (input[len]=='\n' || input[len]=='\r')) {
  912. input[len] = '\0';
  913. }
  914. ZVAL_STRINGL(&argn, input, len + 1);
  915. zend_hash_str_update(&EG(symbol_table), "argn", sizeof("argn")-1, &argn);
  916. ZVAL_LONG(&argi, ++index);
  917. zend_hash_str_update(&EG(symbol_table), "argi", sizeof("argi")-1, &argi);
  918. if (exec_run) {
  919. if (zend_eval_string_ex(exec_run, NULL, "Command line run code", 1) == FAILURE) {
  920. exit_status=254;
  921. }
  922. } else {
  923. if (script_file) {
  924. if (cli_seek_file_begin(&file_handle, script_file, &lineno) != SUCCESS) {
  925. exit_status = 1;
  926. } else {
  927. CG(start_lineno) = lineno;
  928. php_execute_script(&file_handle);
  929. exit_status = EG(exit_status);
  930. }
  931. }
  932. }
  933. efree(input);
  934. }
  935. if (exec_end && zend_eval_string_ex(exec_end, NULL, "Command line end code", 1) == FAILURE) {
  936. exit_status=254;
  937. }
  938. break;
  939. }
  940. case PHP_MODE_REFLECTION_FUNCTION:
  941. case PHP_MODE_REFLECTION_CLASS:
  942. case PHP_MODE_REFLECTION_EXTENSION:
  943. case PHP_MODE_REFLECTION_ZEND_EXTENSION:
  944. {
  945. zend_class_entry *pce = NULL;
  946. zval arg, ref;
  947. zend_execute_data execute_data;
  948. switch (behavior) {
  949. default:
  950. break;
  951. case PHP_MODE_REFLECTION_FUNCTION:
  952. if (strstr(reflection_what, "::")) {
  953. pce = reflection_method_ptr;
  954. } else {
  955. pce = reflection_function_ptr;
  956. }
  957. break;
  958. case PHP_MODE_REFLECTION_CLASS:
  959. pce = reflection_class_ptr;
  960. break;
  961. case PHP_MODE_REFLECTION_EXTENSION:
  962. pce = reflection_extension_ptr;
  963. break;
  964. case PHP_MODE_REFLECTION_ZEND_EXTENSION:
  965. pce = reflection_zend_extension_ptr;
  966. break;
  967. }
  968. ZVAL_STRING(&arg, reflection_what);
  969. object_init_ex(&ref, pce);
  970. memset(&execute_data, 0, sizeof(zend_execute_data));
  971. EG(current_execute_data) = &execute_data;
  972. zend_call_method_with_1_params(&ref, pce, &pce->constructor, "__construct", NULL, &arg);
  973. if (EG(exception)) {
  974. zval tmp, *msg, rv;
  975. ZVAL_OBJ(&tmp, EG(exception));
  976. msg = zend_read_property(zend_ce_exception, &tmp, "message", sizeof("message")-1, 0, &rv);
  977. zend_printf("Exception: %s\n", Z_STRVAL_P(msg));
  978. zval_ptr_dtor(&tmp);
  979. EG(exception) = NULL;
  980. } else {
  981. zend_call_method_with_1_params(NULL, reflection_ptr, NULL, "export", NULL, &ref);
  982. }
  983. zval_ptr_dtor(&ref);
  984. zval_ptr_dtor(&arg);
  985. break;
  986. }
  987. case PHP_MODE_REFLECTION_EXT_INFO:
  988. {
  989. int len = (int)strlen(reflection_what);
  990. char *lcname = zend_str_tolower_dup(reflection_what, len);
  991. zend_module_entry *module;
  992. if ((module = zend_hash_str_find_ptr(&module_registry, lcname, len)) == NULL) {
  993. if (!strcmp(reflection_what, "main")) {
  994. display_ini_entries(NULL);
  995. } else {
  996. zend_printf("Extension '%s' not present.\n", reflection_what);
  997. exit_status = 1;
  998. }
  999. } else {
  1000. php_info_print_module(module);
  1001. }
  1002. efree(lcname);
  1003. break;
  1004. }
  1005. case PHP_MODE_SHOW_INI_CONFIG:
  1006. {
  1007. zend_printf("Configuration File (php.ini) Path: %s\n", PHP_CONFIG_FILE_PATH);
  1008. zend_printf("Loaded Configuration File: %s\n", php_ini_opened_path ? php_ini_opened_path : "(none)");
  1009. zend_printf("Scan for additional .ini files in: %s\n", php_ini_scanned_path ? php_ini_scanned_path : "(none)");
  1010. zend_printf("Additional .ini files parsed: %s\n", php_ini_scanned_files ? php_ini_scanned_files : "(none)");
  1011. break;
  1012. }
  1013. }
  1014. } zend_end_try();
  1015. out:
  1016. if (request_started) {
  1017. php_request_shutdown((void *) 0);
  1018. }
  1019. if (translated_path) {
  1020. free(translated_path);
  1021. }
  1022. if (exit_status == 0) {
  1023. exit_status = EG(exit_status);
  1024. }
  1025. return exit_status;
  1026. err:
  1027. sapi_deactivate();
  1028. zend_ini_deactivate();
  1029. exit_status = 1;
  1030. goto out;
  1031. }
  1032. /* }}} */
  1033. /* {{{ main
  1034. */
  1035. #ifdef PHP_CLI_WIN32_NO_CONSOLE
  1036. int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nShowCmd)
  1037. #else
  1038. int main(int argc, char *argv[])
  1039. #endif
  1040. {
  1041. #if defined(PHP_WIN32)
  1042. # ifdef PHP_CLI_WIN32_NO_CONSOLE
  1043. int argc = __argc;
  1044. char **argv = __argv;
  1045. # else
  1046. int num_args;
  1047. wchar_t **argv_wide;
  1048. char **argv_save = argv;
  1049. BOOL using_wide_argv = 0;
  1050. # endif
  1051. #endif
  1052. int c;
  1053. int exit_status = SUCCESS;
  1054. int module_started = 0, sapi_started = 0;
  1055. char *php_optarg = NULL;
  1056. int php_optind = 1, use_extended_info = 0;
  1057. char *ini_path_override = NULL;
  1058. char *ini_entries = NULL;
  1059. int ini_entries_len = 0;
  1060. int ini_ignore = 0;
  1061. sapi_module_struct *sapi_module = &cli_sapi_module;
  1062. /*
  1063. * Do not move this initialization. It needs to happen before argv is used
  1064. * in any way.
  1065. */
  1066. argv = save_ps_args(argc, argv);
  1067. cli_sapi_module.additional_functions = additional_functions;
  1068. #if defined(PHP_WIN32) && defined(_DEBUG) && defined(PHP_WIN32_DEBUG_HEAP)
  1069. {
  1070. int tmp_flag;
  1071. _CrtSetReportMode(_CRT_WARN, _CRTDBG_MODE_FILE);
  1072. _CrtSetReportFile(_CRT_WARN, _CRTDBG_FILE_STDERR);
  1073. _CrtSetReportMode(_CRT_ERROR, _CRTDBG_MODE_FILE);
  1074. _CrtSetReportFile(_CRT_ERROR, _CRTDBG_FILE_STDERR);
  1075. _CrtSetReportMode(_CRT_ASSERT, _CRTDBG_MODE_FILE);
  1076. _CrtSetReportFile(_CRT_ASSERT, _CRTDBG_FILE_STDERR);
  1077. tmp_flag = _CrtSetDbgFlag(_CRTDBG_REPORT_FLAG);
  1078. tmp_flag |= _CRTDBG_DELAY_FREE_MEM_DF;
  1079. tmp_flag |= _CRTDBG_LEAK_CHECK_DF;
  1080. _CrtSetDbgFlag(tmp_flag);
  1081. }
  1082. #endif
  1083. #ifdef HAVE_SIGNAL_H
  1084. #if defined(SIGPIPE) && defined(SIG_IGN)
  1085. signal(SIGPIPE, SIG_IGN); /* ignore SIGPIPE in standalone mode so
  1086. that sockets created via fsockopen()
  1087. don't kill PHP if the remote site
  1088. closes it. in apache|apxs mode apache
  1089. does that for us! thies@thieso.net
  1090. 20000419 */
  1091. #endif
  1092. #endif
  1093. #ifdef ZTS
  1094. tsrm_startup(1, 1, 0, NULL);
  1095. (void)ts_resource(0);
  1096. ZEND_TSRMLS_CACHE_UPDATE();
  1097. #endif
  1098. zend_signal_startup();
  1099. #ifdef PHP_WIN32
  1100. _fmode = _O_BINARY; /*sets default for file streams to binary */
  1101. setmode(_fileno(stdin), O_BINARY); /* make the stdio mode be binary */
  1102. setmode(_fileno(stdout), O_BINARY); /* make the stdio mode be binary */
  1103. setmode(_fileno(stderr), O_BINARY); /* make the stdio mode be binary */
  1104. #endif
  1105. while ((c = php_getopt(argc, argv, OPTIONS, &php_optarg, &php_optind, 0, 2))!=-1) {
  1106. switch (c) {
  1107. case 'c':
  1108. if (ini_path_override) {
  1109. free(ini_path_override);
  1110. }
  1111. ini_path_override = strdup(php_optarg);
  1112. break;
  1113. case 'n':
  1114. ini_ignore = 1;
  1115. break;
  1116. case 'd': {
  1117. /* define ini entries on command line */
  1118. int len = (int)strlen(php_optarg);
  1119. char *val;
  1120. if ((val = strchr(php_optarg, '='))) {
  1121. val++;
  1122. if (!isalnum(*val) && *val != '"' && *val != '\'' && *val != '\0') {
  1123. ini_entries = realloc(ini_entries, ini_entries_len + len + sizeof("\"\"\n\0"));
  1124. memcpy(ini_entries + ini_entries_len, php_optarg, (val - php_optarg));
  1125. ini_entries_len += (int)(val - php_optarg);
  1126. memcpy(ini_entries + ini_entries_len, "\"", 1);
  1127. ini_entries_len++;
  1128. memcpy(ini_entries + ini_entries_len, val, len - (val - php_optarg));
  1129. ini_entries_len += len - (int)(val - php_optarg);
  1130. memcpy(ini_entries + ini_entries_len, "\"\n\0", sizeof("\"\n\0"));
  1131. ini_entries_len += sizeof("\n\0\"") - 2;
  1132. } else {
  1133. ini_entries = realloc(ini_entries, ini_entries_len + len + sizeof("\n\0"));
  1134. memcpy(ini_entries + ini_entries_len, php_optarg, len);
  1135. memcpy(ini_entries + ini_entries_len + len, "\n\0", sizeof("\n\0"));
  1136. ini_entries_len += len + sizeof("\n\0") - 2;
  1137. }
  1138. } else {
  1139. ini_entries = realloc(ini_entries, ini_entries_len + len + sizeof("=1\n\0"));
  1140. memcpy(ini_entries + ini_entries_len, php_optarg, len);
  1141. memcpy(ini_entries + ini_entries_len + len, "=1\n\0", sizeof("=1\n\0"));
  1142. ini_entries_len += len + sizeof("=1\n\0") - 2;
  1143. }
  1144. break;
  1145. }
  1146. #ifndef PHP_CLI_WIN32_NO_CONSOLE
  1147. case 'S':
  1148. sapi_module = &cli_server_sapi_module;
  1149. cli_server_sapi_module.additional_functions = server_additional_functions;
  1150. break;
  1151. #endif
  1152. case 'h': /* help & quit */
  1153. case '?':
  1154. php_cli_usage(argv[0]);
  1155. goto out;
  1156. case 'i': case 'v': case 'm':
  1157. sapi_module = &cli_sapi_module;
  1158. goto exit_loop;
  1159. case 'e': /* enable extended info output */
  1160. use_extended_info = 1;
  1161. break;
  1162. }
  1163. }
  1164. exit_loop:
  1165. sapi_module->ini_defaults = sapi_cli_ini_defaults;
  1166. sapi_module->php_ini_path_override = ini_path_override;
  1167. sapi_module->phpinfo_as_text = 1;
  1168. sapi_module->php_ini_ignore_cwd = 1;
  1169. sapi_startup(sapi_module);
  1170. sapi_started = 1;
  1171. sapi_module->php_ini_ignore = ini_ignore;
  1172. sapi_module->executable_location = argv[0];
  1173. if (sapi_module == &cli_sapi_module) {
  1174. if (ini_entries) {
  1175. ini_entries = realloc(ini_entries, ini_entries_len + sizeof(HARDCODED_INI));
  1176. memmove(ini_entries + sizeof(HARDCODED_INI) - 2, ini_entries, ini_entries_len + 1);
  1177. memcpy(ini_entries, HARDCODED_INI, sizeof(HARDCODED_INI) - 2);
  1178. } else {
  1179. ini_entries = malloc(sizeof(HARDCODED_INI));
  1180. memcpy(ini_entries, HARDCODED_INI, sizeof(HARDCODED_INI));
  1181. }
  1182. ini_entries_len += sizeof(HARDCODED_INI) - 2;
  1183. }
  1184. sapi_module->ini_entries = ini_entries;
  1185. /* startup after we get the above ini override se we get things right */
  1186. if (sapi_module->startup(sapi_module) == FAILURE) {
  1187. /* there is no way to see if we must call zend_ini_deactivate()
  1188. * since we cannot check if EG(ini_directives) has been initialised
  1189. * because the executor's constructor does not set initialize it.
  1190. * Apart from that there seems no need for zend_ini_deactivate() yet.
  1191. * So we goto out_err.*/
  1192. exit_status = 1;
  1193. goto out;
  1194. }
  1195. module_started = 1;
  1196. #if defined(PHP_WIN32) && !defined(PHP_CLI_WIN32_NO_CONSOLE)
  1197. php_win32_cp_cli_setup();
  1198. orig_cp = (php_win32_cp_get_orig())->id;
  1199. /* Ignore the delivered argv and argc, read from W API. This place
  1200. might be too late though, but this is the earliest place ATW
  1201. we can access the internal charset information from PHP. */
  1202. argv_wide = CommandLineToArgvW(GetCommandLineW(), &num_args);
  1203. PHP_WIN32_CP_W_TO_ANY_ARRAY(argv_wide, num_args, argv, argc)
  1204. using_wide_argv = 1;
  1205. SetConsoleCtrlHandler(php_cli_win32_ctrl_handler, TRUE);
  1206. #endif
  1207. /* -e option */
  1208. if (use_extended_info) {
  1209. CG(compiler_options) |= ZEND_COMPILE_EXTENDED_INFO;
  1210. }
  1211. zend_first_try {
  1212. #ifndef PHP_CLI_WIN32_NO_CONSOLE
  1213. if (sapi_module == &cli_sapi_module) {
  1214. #endif
  1215. exit_status = do_cli(argc, argv);
  1216. #ifndef PHP_CLI_WIN32_NO_CONSOLE
  1217. } else {
  1218. exit_status = do_cli_server(argc, argv);
  1219. }
  1220. #endif
  1221. } zend_end_try();
  1222. out:
  1223. if (ini_path_override) {
  1224. free(ini_path_override);
  1225. }
  1226. if (ini_entries) {
  1227. free(ini_entries);
  1228. }
  1229. if (module_started) {
  1230. php_module_shutdown();
  1231. }
  1232. if (sapi_started) {
  1233. sapi_shutdown();
  1234. }
  1235. #ifdef ZTS
  1236. tsrm_shutdown();
  1237. #endif
  1238. #if defined(PHP_WIN32) && !defined(PHP_CLI_WIN32_NO_CONSOLE)
  1239. (void)php_win32_cp_cli_restore();
  1240. if (using_wide_argv) {
  1241. PHP_WIN32_CP_FREE_ARRAY(argv, argc);
  1242. LocalFree(argv_wide);
  1243. }
  1244. argv = argv_save;
  1245. #endif
  1246. /*
  1247. * Do not move this de-initialization. It needs to happen right before
  1248. * exiting.
  1249. */
  1250. cleanup_ps_args(argv);
  1251. exit(exit_status);
  1252. }
  1253. /* }}} */
  1254. /*
  1255. * Local variables:
  1256. * tab-width: 4
  1257. * c-basic-offset: 4
  1258. * End:
  1259. * vim600: sw=4 ts=4 fdm=marker
  1260. * vim<600: sw=4 ts=4
  1261. */