Re: Perl path directory greek

Comment on Re: Perl path directory greek

Replies are listed 'Best First'.
Re^2: Perl path directory greek by afoken (Chancellor) on Nov 21, 2010 at 00:37 UTC
Looks promising, but the documentation reads more like chinese than english, and the code still has some strange lines (see below). Use with caution. Problems I see from looking at the code of v0.24: In `Win32::Unicode::Console::_ConsoleOut()`, `warn` is called. I think that line should `print STDERR` instead, but I'm not 100% sure. Several functions (`Win32::Unicode::Console::dieW()`, `Win32::Unicode::Console::warnW()`, `Win32::Unicode::Dir::_croakW`, `Win32::Unicode::File::_croakW`, `Win32::Unicode::File::_carpW`) call `Win32::Unicode::Console::_row_warn()` before `warn()`ing or `die()`ing, which calls `Win32::Unicode::Console::_ConsoleOut()` and thus may call `warn()`, causing repeated or additional calls to a `$SIG{__WARN__}` handler. In `Win32::Unicode::Constant`: TRUE and FALSE, oh well. INFINITE is 0xFFFFFFFF? And what magic numbers hide in `sub CONSOLE_OUTPUT_HANDLE() { +{7 => 1, 11 => 1, 15 => 1} }` and `sub CONSOLE_ERROR_HANDLE() { +{11 => 1, 15 => 1} }`? ~~`Win32::Unicode::Error::errorW()` should perhaps call `format_message()`, not `foramt_message()`.~~ Nope, the same typo is in `Error.xs`. `Win32::Unicode::Util::to64int()` hides a `use bigint`, should have gone since 0.23 according to the `Changes` file. Perhaps this was meant to be `require bigint`? `$Win32::Unicode::Process::SHELL` may be initialised to a constant `C:/WINDOWS/system32/cmd.exe`, even if Windows is installed elsewhere (`C:\WinNT` was common for NT 4 and W2K). `Win32::Unicode::Process::_create_process()` does some strange things with quotes and the command shell instead of calling the native `CreateProcessA()`/`CreateProcessW()` functions. Even the author thinks that code might open a security hole. Both `Win32::Unicode::Process::systemW()` and `Win32::Unicode::Process::execW()` wrap this function. Loading `Win32::Unicode::Native` erases the `@ARGV` array and replaces it with postprocessed values returned by `CommandLineToArgvW()`, including some special cases for "-e", "-", and `$0`. I think it may be possible to confuse the code, so that `@ARGV` ends up with too many or too few arguments (UNTESTED). For Perl >= 5.10, the code lacks special processing for "-E". And for binaries loading perl5xx.dll instead of invoking perl.exe, the code may become completely confused (UNTESTED). Also in `Win32::Unicode::Native`: `sub __FILE__ () { $script }` looks very strange. Was that meant to replace `__FILE__` in `main`? `Win32::Unicode::File::open()` does not support layers (à la `open my $f,'<:utf8',$name`). It also does not support pipes (this is documented). `Win32::Unicode::File::filename_normalize()` replaces several characters in filenames with other strange characters (see `%win32_taboo`). Alexander -- Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^2: Perl path directory greek
by afoken (Chancellor) on Nov 21, 2010 at 00:37 UTC

Looks promising, but the documentation reads more like chinese than english, and the code still has some strange lines (see below). Use with caution.

Problems I see from looking at the code of v0.24:

In Win32::Unicode::Console::_ConsoleOut(), warn is called. I think that line should print STDERR instead, but I'm not 100% sure.
Several functions (Win32::Unicode::Console::dieW(), Win32::Unicode::Console::warnW(), Win32::Unicode::Dir::_croakW, Win32::Unicode::File::_croakW, Win32::Unicode::File::_carpW) call Win32::Unicode::Console::_row_warn() before warn()ing or die()ing, which calls Win32::Unicode::Console::_ConsoleOut() and thus may call warn(), causing repeated or additional calls to a $SIG{__WARN__} handler.
In Win32::Unicode::Constant: TRUE and FALSE, oh well. INFINITE is 0xFFFFFFFF? And what magic numbers hide in sub CONSOLE_OUTPUT_HANDLE() { +{7 => 1, 11 => 1, 15 => 1} } and sub CONSOLE_ERROR_HANDLE() { +{11 => 1, 15 => 1} }?
~~Win32::Unicode::Error::errorW() should perhaps call format_message(), not foramt_message().~~ Nope, the same typo is in Error.xs.
Win32::Unicode::Util::to64int() hides a use bigint, should have gone since 0.23 according to the Changes file. Perhaps this was meant to be require bigint?
$Win32::Unicode::Process::SHELL may be initialised to a constant C:/WINDOWS/system32/cmd.exe, even if Windows is installed elsewhere (C:\WinNT was common for NT 4 and W2K).
Win32::Unicode::Process::_create_process() does some strange things with quotes and the command shell instead of calling the native CreateProcessA()/CreateProcessW() functions. Even the author thinks that code might open a security hole. Both Win32::Unicode::Process::systemW() and Win32::Unicode::Process::execW() wrap this function.
Loading Win32::Unicode::Native erases the @ARGV array and replaces it with postprocessed values returned by CommandLineToArgvW(), including some special cases for "-e", "-", and $0. I think it may be possible to confuse the code, so that @ARGV ends up with too many or too few arguments (UNTESTED). For Perl >= 5.10, the code lacks special processing for "-E". And for binaries loading perl5xx.dll instead of invoking perl.exe, the code may become completely confused (UNTESTED).
Also in Win32::Unicode::Native: sub __FILE__ () { $script } looks very strange. Was that meant to replace __FILE__ in main?
Win32::Unicode::File::open() does not support layers (à la open my $f,'<:utf8',$name). It also does not support pipes (this is documented).
Win32::Unicode::File::filename_normalize() replaces several characters in filenames with other strange characters (see %win32_taboo).

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom