convenience methods for encoding external process calls

Why not shOne:encoding: implementing shOne: in terms of it and the default encoding?  Then you've got two methods, not N.

On Thu, Apr 22, 2010 at 1:59 PM, Alan Knight <[hidden email]> wrote:

One of the things that changed in 7.7 was that forking an external process on Windows via shOne: started consistently using Unicode (i.e. UTF-16) and the /u shell argument when doing it. Not all programs respect this, so while it made some things start giving back correct results for the first time, other things started giving back badly encoded results. This has caused a reasonable amount of confusion.

It's pretty easy to interpret the process results with any encoding you want, just by doing something like

   p := ExternalProcess new.

   p encoding: #JIS.

   ^p fork: 'someProgram' arguments: (Array with: '123').

but people would need to know that, where they've been used to just using shOne:.  So it seems like it would be a good idea to provide a convenience API that does what people are used to. But the question is what to call it. So, for example

WinProcess>>shOneOEM: aString

    self encoding: (OSSystemSupport concreteClass new GetOEMCP printString asSymbol).

   ^self fork: self getCommandLineInterpreter arguments: (Array with: '/c' with: aString).

which would run the command using the OEM encoding, which is the most likely thing programs are going to use if they're not using UTF-16 like good citizens. On North American Windows, that means code page 437.

But if people aren't aware of the distinction, they're probably not going to know that OEM is the right term. Other suggestions included:

shOne8Bit:

shOneNonUnicode:

or even just

cmd:

Any preferences, or better ideas?  I thought it might also be worthwhile to provide shOneBinary:, which is just the same thing except it sets the encoding to #binary, but people might not be aware they can do that. Is that worthwhile, or just clutter?

--

Alan Knight [|], Engineering Manager, Cincom Smalltalk

[hidden email]

[hidden email]

http://www.cincom.com/smalltalk

_______________________________________________

vwnc mailing list

[hidden email]

http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

the selector / class names of ExternalProcess have always confused me:

- #cshOne: - as the comment already says, it's Unix-specific. And what's
the meaning of the suffix "One"? My first thought was "channel one aka
stdout(1)", but it returns the output of channel stderr(2) if there is
any output.

- #fork: - it waits for the command to finish, so calling the method
"fork" is misleading. Forking is actually done in #startProcess:arguments:

- #shOne: - same issues as #cshOne:. "sh" is a Unix-specific name, too.

- ExternalProcess is command-line-centric

     WinProcess new startProcess: 'notepad' arguments: #()
     Win32SystemSupport CreateProcess: nil arguments: 'notepad'

suggestions for new selectors:

1. replacement for fork:arguments:

   runExecutable:arguments:
     or
   runCommandLineExecutable:arguments:
     or
   run:arguments:

2. replacement for shOne:

   runCommandLine:

3. additional method to solve the encoding issue:

   runCommandLine: aString forceByteEncoding: aBoolean

The implementation of this method could use two internal methods (e.g.
#runCommandLineWithDefaultEncoding: and
#runCommandLineWithByteEncoding:), or use some switches, or whatever ;)

the important part is that the selector does not
- mention any specific encoding
- use abbreviations like "sh"

Am 22.04.2010 22:59, schrieb Alan Knight:
> One of the things that changed in 7.7 was that forking an external
> process on Windows via shOne: started consistently using Unicode (i.e.
> UTF-16) and the /u shell argument when doing it. Not all programs
> respect this, so while it made some things start giving back correct
> results for the first time, other things started giving back badly
> encoded results. This has caused a reasonable amount of confusion.
>
> It's pretty easy to interpret the process results with any encoding you
> want, just by doing something like
> p := ExternalProcess new.
> p encoding: #JIS.
> ^p fork: 'someProgram' arguments: (Array with: '123').
>
> but people would need to know that, where they've been used to just
> using shOne:. So it seems like it would be a good idea to provide a
> convenience API that does what people are used to. But the question is
> what to call it. So, for example
>
> WinProcess>>shOneOEM: aString
> self encoding: (OSSystemSupport concreteClass new GetOEMCP printString
> asSymbol).
> ^self fork: self getCommandLineInterpreter arguments: (Array with: '/c'
> with: aString).
>
> which would run the command using the OEM encoding, which is the most
> likely thing programs are going to use if they're not using UTF-16 like
> good citizens. On North American Windows, that means code page 437.
>
> But if people aren't aware of the distinction, they're probably not
> going to know that OEM is the right term. Other suggestions included:
>
> shOne8Bit:
> shOneNonUnicode:
> or even just
> cmd:
>
> Any preferences, or better ideas? I thought it might also be worthwhile
> to provide shOneBinary:, which is just the same thing except it sets the
> encoding to #binary, but people might not be aware they can do that. Is
> that worthwhile, or just clutter?
>
>
> --
> Alan Knight [|], Engineering Manager, Cincom Smalltalk
> [hidden email]
> [hidden email]
> http://www.cincom.com/smalltalk
>
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc