Smalltalk › Cincom › VisualWorks

ExternalProcess woes

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

2 messages Options

Jan Weerts

ExternalProcess woes

Hi all!

Lately i tried to use ExternalProcess to start some CMD-script based
actions on Windows. One script used the "START" command to start
subprocesses. Since the I/O of these is linked to the parents I/O, a
call to #fork:arguments: will wait until these subprocesses are
finished/stopped. While learning this I tried to place a timeout
around the invocation which also hung, because of the spawned error
reader process in #execute:arguments:do:errorStreamDo:. So I added a
#ifCurtailed: which ends the error reader and execution continued. But
the image froze as soon as some garbage collection started and only
returned, when the external subprocesses were ended. This I did not
research, instead we now use OSSystemSupport>>#executeAndWait:in:.
Btw. totally ignoring the output of the invoked script lead to an
early interruption of the script.

Looking at ExternalProcess some oddities arose:
- #shOne: is defined in ExternalProcess instead of UnixProcess. It
already uses #getCommandLineInterpreter but always "-c" to invoke a
script which will fail on windows.
- WinProcess defines #new, which is also available in ExternalProcess
and leads to double initialization
- ExternalProcesses always need to have an encoding on the I/O
streams, which differs from at least Unix semantics for pipes.
#lineEndConvention at least has a transparent switch, but "no
convention" should also be possible.

The attached file was created on 7.7(.0) but seems to be still valid
on 7.8.

Regards
Jan

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

OS-ExternalProcess-Patches.st (3K) Download Attachment

Alan Knight-2

Re: ExternalProcess woes

I've never tried using the START command, but with respect to your other points...

I suspect that to have a timeout on an invocation like that that yes, you'd need to terminate both the input and error reading processes or it wouldn't cleanly exit. Although I'd think that terminating the Windows process would also do it.

The shOne: is defined in the superclass. And if you're on Windows it doesn't really do a shell, it invokes the Windows command interpreter. This is a little odd, but people got quite comfortable using shOne: and even cshOne: as the protocol for doing any external invocation, even where it didn't make a lot of sense, and even though those were marked as example methods. So we've retained that protocol, and people generally seem to understand it. As far as I know it works fine on Windows, whether invoked on the class or instance side. The use of -c shouldn't happen, because shOne: is defined in WindowsProcess to do something different.

The double initialize is a good catch. ExternalProcess is doing some cleverness there to create the right subclass, but doesn't get it quite right. It should be harmless, apart from doing extra work. Created AR 63571.

Encoding #binary is equivalent to no encoding. But if you're doing that, you'd want to use fork:arguments: rather than shOne:, which at least in those versions will tell the shell to use Unicode i.e. UTF-16 encoding, and force the streams appropriately. So, e.g.
(ExternalProcess new encoding: #binary; fork: 'ipconfig') asStringEncoding: #'ms-cp-1252'

[hidden email]
14 July, 2011 10:30 AM

Hi all!

Lately i tried to use ExternalProcess to start some CMD-script based actions on Windows. One script used the "START" command to start subprocesses. Since the I/O of these is linked to the parents I/O, a call to #fork:arguments: will wait until these subprocesses are finished/stopped. While learning this I tried to place a timeout around the invocation which also hung, because of the spawned error reader process in #execute:arguments:do:errorStreamDo:. So I added a #ifCurtailed: which ends the error reader and execution continued. But the image froze as soon as some garbage collection started and only returned, when the external subprocesses were ended. This I did not research, instead we now use OSSystemSupport>>#executeAndWait:in:.
Btw. totally ignoring the output of the invoked script lead to an early interruption of the script.

Looking at ExternalProcess some oddities arose:
- #shOne: is defined in ExternalProcess instead of UnixProcess. It already uses #getCommandLineInterpreter but always "-c" to invoke a script which will fail on windows.
- WinProcess defines #new, which is also available in ExternalProcess and leads to double initialization
- ExternalProcesses always need to have an encoding on the I/O streams, which differs from at least Unix semantics for pipes. #lineEndConvention at least has a transparent switch, but "no convention" should also be possible.

The attached file was created on 7.7(.0) but seems to be still valid on 7.8.

Regards
Jan

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc