Hi,

I don't know the windows situation at all, but I'm wondering.

([ File stdioDescriptorIsATTY not ]
on: PrimitiveFailed
do: [ :ex | "HACK kept for retrocompatibility" Smalltalk os isWin32 ])
ifTrue: [ ^ self createStdioFileFor: moniker ].

the first thing I would do, just trying to keep the same behaviour, is to invert the test... Something like

Smalltalk os isWin32 ifTrue: [
[ File stdioDescriptorIsATTY not ]
on: PrimitiveFailed
do: [ :ex | false ])
ifTrue: [ ^ self createStdioFileFor: moniker ]. ]

Like that, this would only penalise windows in the worst case. Then a first question arises in my head: why isWin32 and not��isWindows? Is there a reason behind that? Wouldn't that prevent correct behaviour in windows 64 bits?

My next impression is that testing for "a TTY or a file or a pipe" seems buggy... We should put a more intention revealing selector like #isInvalidStdioHandle?
A more high level test will allow us to do any check we want��in the background, and it allows better to understand why we check for TTY or File or Pipe or la mar en coche :)

On Thu, Aug 2, 2018 at 8:54 PM Alistair Grant <akgrant0710@gmail.com> wrote:
File class>>stdioHandles calls primitiveFileStdioHandles() which
eventually opens the stdio streams (if possible) using the Windows
native GetStdHandle() function.

What does #stdioHandles return to the image in the case of a non-console windows VM? I mean, when "it is not possible"?

From the docs, https://docs.microsoft.com/en-us/windows/console/getstdhandle says we may have an INVALID_HANDLE_VALUE or NULL in case it fails.
Is the file plugin is masking the error? If so, thats why we need such strange��workarounds...

��- If it is an invalid handle,��why not just testing for "isInvalidHandle" or so? We can have that on the image side and then dispatch to the correct thing in the file plugin maybe?

��- Maybe the #stdioHandles primitive should just fail in the case we don't have correct handles? that would allow us to do a much more elegant approach on the image side...

> I suspect File needs a nameless variant (I'm not certain how pipes
> work in unix but I doubt echo foo | cat ever touches the filesystem)

That's my understanding (it doesn't touch the file system).


Well... I see this is just a aesthetic issue and I don't see how this is related to the above more serious issue...