Smalltalk › Squeak › Squeak - Dev

OSProcess stdErr issue on Windows

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

5 messages Options

Ben Coman

OSProcess stdErr issue on Windows

On Windows 7, trying to execute a non-existent program as follows...

OSProcess command: 'notepadXX.exe'

...causes an MNU in ExternalWindowsOSProcess>>value. This is due to writing to stderr where "self initialStdErr" returns nil, seemingly due to ExternalWindowsOSProcess missing the #initialize and #setDefaults of ExternalUnixOSProcess.

Now I understand that stderr is problematic in general on Windows.

The following statements...

OSProcess thisOSProcess stdErr nextPutAll: 'test'.

FileStream stderr nextPutAll: 'test'.

...both work fine on OSX, but fail on Windows with the error "FileWriteError: File stderr is closed"
The result is the same on both Pharo 4 and Squeak 4.5.

(Squeak also brings up a bottom message bar saying... "# To disable: F2 -> 'debug options' -> 'show console on errors' WARNING: Manufactured file handle detected!")

Pharo has a workaround for the general issue by creating a disk file named 'stderr' as follows...

FileStream class >> standardIOStreamNamed: moniker forWrite: forWrite

self flag: #todo. "This is an ugly hack, while waiting for a real fix for windows. There several problems with this approach, but it allow us to run tests, etc."

Smalltalk os isWin32

ifTrue: [

[ ^ MultiByteFileStream forceNewFileNamed: moniker asString ]

on: CannotDeleteFileException do: [

"HACK: if the image is opened a second time windows barks about the already opened locked file"

^ MultiByteFileStream forceNewFileNamed: moniker asString, '_', (Random new nextInt: SmallInteger maxVal) asString ]].

So to address the MNU for OSProcess?

1. wrap the "self initialStdErr" with an #ifNil: check

2. Squeak adopt the Pharo workaround, then lean on that to define #initialize and #setDefaults for ExternalWindowsOSProcess

3. real fix for stderr (outside of OSProcess?)

4. wont fix

5. other?

Note that this is not a burning issue for me. I am just cleaning out old issues that I logged in the Pharo bug tracker. If the answer if (4.) I'll just close the issue [1].

For both Squeak and Pharo, I loaded ConfigurationOfOSProcess-ThierryGoubier.33 from...

MCHttpRepository

location: 'http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo40/main'

(Perhaps someone with access can copy that to the main repo)

cheers -ben

[1] https://pharo.fogbugz.com/default.asp?11615

David T. Lewis

Re: OSProcess stdErr issue on Windows

Thanks Ben,

On Sun, Jan 11, 2015 at 12:36:14PM +0800, Ben Coman wrote:
> On Windows 7, trying to execute a non-existent program as follows...
> OSProcess command: 'notepadXX.exe'
>
> ...causes an MNU in ExternalWindowsOSProcess>>value. This is due to writing
> to stderr where "self initialStdErr" returns nil, seemingly due to
> ExternalWindowsOSProcess missing the #initialize and #setDefaults of E
> xternalUnixOSProcess.

I made the change to prevent this error, and committed it to the OSProcess
repository.

>
> Now I understand that stderr is problematic in general on Windows.
> The following statements...
> OSProcess thisOSProcess stdErr nextPutAll: 'test'.
> FileStream stderr nextPutAll: 'test'.
>
> ...both work fine on OSX, but fail on Windows with the error
> "FileWriteError: File stderr is closed"
> The result is the same on both Pharo 4 and Squeak 4.5.
> (Squeak also brings up a bottom message bar saying... "# To disable: F2 ->
> 'debug options' -> 'show console on errors' WARNING: Manufactured file
> handle detected!")

A word of explanation is in order here. There is a handle registry in the
Windows support code for FilePlugin that was added specifically to prevent
use of "manufactured" file handles. I think that the idea was enhance
security, although in practice the only effect is to prevent OSProcess
from attaching to pipes and stdio streams.

A workaround would be to provide an external FilePlugin dll with the
handle registry disabled.

>
> Pharo has a workaround for the general issue by creating a disk file
> named 'stderr'
> as follows...
> FileStream class >> standardIOStreamNamed: moniker forWrite: forWrite
> self flag: #todo. "This is an ugly hack, while waiting for a real fix for
> windows. There several problems with this approach, but it allow us to run
> tests, etc."
> Smalltalk os isWin32
> ifTrue: [
> [ ^ MultiByteFileStream forceNewFileNamed: moniker asString ]
> on: CannotDeleteFileException do: [
> "HACK: if the image is opened a second time windows barks about the already
> opened locked file"
> ^ MultiByteFileStream forceNewFileNamed: moniker asString, '_', (Random new
> nextInt: SmallInteger maxVal) asString ]].
>
> So to address the MNU for OSProcess?
> 1. wrap the "self initialStdErr" with an #ifNil: check
> 2. Squeak adopt the Pharo workaround, then lean on that to define
> #initialize and #setDefaults for ExternalWindowsOSProcess
> 3. real fix for stderr (outside of OSProcess?)
> 4. wont fix
> 5. other?
>
>
> Note that this is not a burning issue for me. I am just cleaning out old
> issues that I logged in the Pharo bug tracker. If the answer if (4.) I'll
> just close the issue [1].

I did #1, and hopefully that will take care of the issue.

>
>
> For both Squeak and Pharo, I
> loaded ConfigurationOfOSProcess-ThierryGoubier.33 from...
> MCHttpRepository
> location: 'http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo40/main'
> (Perhaps someone with access can copy that to the main repo)
>

I copied ConfigurationOfOSProcess-ThierryGoubier.33 to the OSProcess
repository. An update to ConfigurationOfOSProcess will be needed to
get the latest version (Thierry, can you do this?).

For Squeak, no ConfigurationOfOSProcess is needed, just use the latest
version (with SqueakMap, or currently it OSProcess-dtl.93 in the repo).

Pharo should also use the latest version if possible, although the
Metacello configurations are needed to make things work on various older
Pharo versions. The versions for a current spec would be:

OSProcess-Base-dtl.46
OSProcess-Unix-dtl.20
OSProcess-Win32-dtl.12
OSProcess-Mac-dtl.2
OSProcess-OS2-dtl.2
OSProcess-RiscOS-dtl.2
OSProcess-AIO-dtl.8
Tests-OSProcess-dtl.21

>
> cheers -ben
>
> [1] https://pharo.fogbugz.com/default.asp?11615

Thanks a lot for reporting this!

Dave

David T. Lewis

Re: [Pharo-dev] [squeak-dev] OSProcess stdErr issue on Windows

On Sun, Jan 11, 2015 at 02:42:01PM -0500, David T. Lewis wrote:

>
> I copied ConfigurationOfOSProcess-ThierryGoubier.33 to the OSProcess
> repository. An update to ConfigurationOfOSProcess will be needed to
> get the latest version (Thierry, can you do this?).
>
> For Squeak, no ConfigurationOfOSProcess is needed, just use the latest
> version (with SqueakMap, or currently it OSProcess-dtl.93 in the repo).
>
> Pharo should also use the latest version if possible, although the
> Metacello configurations are needed to make things work on various older
> Pharo versions. The versions for a current spec would be:
>
> OSProcess-Base-dtl.46
> OSProcess-Unix-dtl.20
> OSProcess-Win32-dtl.12
> OSProcess-Mac-dtl.2
> OSProcess-OS2-dtl.2
> OSProcess-RiscOS-dtl.2
> OSProcess-AIO-dtl.8
> Tests-OSProcess-dtl.21
>

Oops, sorry. That should be OSProcess-Tests-dtl.12, not Tests-OSProcess-dtl.21.

Dave

David T. Lewis

Re: [Pharo-dev] [squeak-dev] OSProcess stdErr issue on Windows

On Sun, Jan 11, 2015 at 03:07:59PM -0500, David T. Lewis wrote:

> On Sun, Jan 11, 2015 at 02:42:01PM -0500, David T. Lewis wrote:
> >
> > I copied ConfigurationOfOSProcess-ThierryGoubier.33 to the OSProcess
> > repository. An update to ConfigurationOfOSProcess will be needed to
> > get the latest version (Thierry, can you do this?).
> >
> > For Squeak, no ConfigurationOfOSProcess is needed, just use the latest
> > version (with SqueakMap, or currently it OSProcess-dtl.93 in the repo).
> >
> > Pharo should also use the latest version if possible, although the
> > Metacello configurations are needed to make things work on various older
> > Pharo versions. The versions for a current spec would be:
> >
> > OSProcess-Base-dtl.46
> > OSProcess-Unix-dtl.20
> > OSProcess-Win32-dtl.12
> > OSProcess-Mac-dtl.2
> > OSProcess-OS2-dtl.2
> > OSProcess-RiscOS-dtl.2
> > OSProcess-AIO-dtl.8
> > Tests-OSProcess-dtl.21
> >
>
> Oops, sorry. That should be OSProcess-Tests-dtl.12, not Tests-OSProcess-dtl.21.

Sorry to keep replying to myself, but I noticed some missing test updates from
the main OSProcess package, so now it is OSProcess-Tests-dtl.13.

Dave

Ben Coman

Re: [Pharo-dev] [squeak-dev] OSProcess stdErr issue on Windows

Thanks Dave. I'll try it out this evening.

cheers -ben

On Mon, Jan 12, 2015 at 4:21 AM, David T. Lewis <[hidden email]> wrote:

On Sun, Jan 11, 2015 at 03:07:59PM -0500, David T. Lewis wrote:
> On Sun, Jan 11, 2015 at 02:42:01PM -0500, David T. Lewis wrote:
> >
> > I copied ConfigurationOfOSProcess-ThierryGoubier.33 to the OSProcess
> > repository. An update to ConfigurationOfOSProcess will be needed to
> > get the latest version (Thierry, can you do this?).
> >
> > For Squeak, no ConfigurationOfOSProcess is needed, just use the latest
> > version (with SqueakMap, or currently it OSProcess-dtl.93 in the repo).
> >
> > Pharo should also use the latest version if possible, although the
> > Metacello configurations are needed to make things work on various older
> > Pharo versions. The versions for a current spec would be:
> >
> > OSProcess-Base-dtl.46
> > OSProcess-Unix-dtl.20
> > OSProcess-Win32-dtl.12
> > OSProcess-Mac-dtl.2
> > OSProcess-OS2-dtl.2
> > OSProcess-RiscOS-dtl.2
> > OSProcess-AIO-dtl.8
> > Tests-OSProcess-dtl.21
> >
>
> Oops, sorry. That should be OSProcess-Tests-dtl.12, not Tests-OSProcess-dtl.21.

Sorry to keep replying to myself, but I noticed some missing test updates from
the main OSProcess package, so now it is OSProcess-Tests-dtl.13.

Dave