Yes, the system forcing the encoding to UTF-16 means that shell commands
which involve characters not in the union of code pages 437 and 1252
will work correctly, but arbitrary external commands may not. Using code
page 437 will work as long as your spreadsheet doesn't contain things
like accented characters or Euro symbols.
The simplest way to avoid the shell encoding being forced is to not use
a shell command but to execute it directly. So, if the command to
convert the string is foo.exe, and you know that you expect its output
to be ascii, then something like
ExternalProcess new encoding: 'ascii'; fork: 'foo' withArguments:
#('inputfile.xls').
I think ascii is probably a better choice than 437 or 1252 for the same
reason utf-16 is useful. If your encoding doesn't match, you'll find out
quickly via an error rather than later via incorrect data.
On 2011-02-03 9:59 AM, Karyn Hurley wrote:
> Seeing a problem comparing 7.4 to 7.7: using cshOne: to execute a .xls
> conversion to a csv file causes an error and it seems to be related to the
> changes in the WinProcess-> executeSingleCommand: aString method. The
> encoding is forced to UTF-16. If I inspect self encoding it evaluates as
> 437 before it's forced. The end result is that the stream ends up with a
> collection of what looks to be chinese characters in 7.7 instead of the a
> string of (english) characters.
>
> Has anyone seen this? The problem is corrected if I comment out the self
> encoding: #'UTF-16' in the executeSingleCommand: aString method.
>
> Thanks for any experience or advice!
> Karyn Hurley
>
--
Alan Knight [|], Engineering Manager, Cincom Smalltalk
[hidden email]
[hidden email]
http://www.cincomsmalltalk.com_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc