WinProcess executeSingleCommand forced encoding problem in 7.7

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

WinProcess executeSingleCommand forced encoding problem in 7.7

Karyn Hurley
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
Karyn Hurley
Reply | Threaded
Open this post in threaded view
|

Re: WinProcess executeSingleCommand forced encoding problem in 7.7

Karyn Hurley
Sorry, I found the posts describing the solution...  
Karyn Hurley
Reply | Threaded
Open this post in threaded view
|

Re: WinProcess executeSingleCommand forced encoding problem in 7.7

Alan Knight-2
In reply to this post by Karyn Hurley
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
Reply | Threaded
Open this post in threaded view
|

Re: WinProcess executeSingleCommand forced encoding problem in 7.7

Karyn Hurley
Thank you for that answer, that works nicely and I like that I'm specifying some general encoding.   If I can ask one more question that comes from the differences in the posts: what's the difference between using your suggestion  and this line: ExternalProcess defaultClass fork: 'foo' arguments: #('inputfile.xls')?

Thanks again,
Karyn Hurley
Karyn Hurley