[Tutor] What am I missing here?

[Nathan Smith]

Hi there,


Thanks for this response! In particular thanks for pointing out my logic 
error regarding the way cmd.exe expects input and how it attaches that 
to the end of the prompt line.

I switched over to winexpect and it actually did start printing the 
prompt line, but either way it's good to know so again, thanks for that.


I had a read through the links provided and admit I'm not sure if I 
understood *all* of it, though I agree with you on the point about how 
the interpreter probably handles booting up.

Interestingly, if I send commands through stdin blindly, eg from my gui 
send:

python

f=open("test.txt","w")

f.write("hi")

f.close()


Then it actually does go through, the file gets created.

the only problem is nothing gets printed to stdout or stderr, or at 
least not that the subprocess can see and thus not that the gui can see.

I'm assuming, as you mentioned, that this is because the interpreter is 
not inheriting those stdout and stderr handles from the cmd.exe?


Is there a work around for this?

The whole point of the proof of concept was to be able to provide a more 
friendly interface for python interpreter from a screen reader 
perspective, so be disappointed if I'm stuck here.


Best,

Nathan

On 12/02/2022 17:49, Dennis Lee Bieber wrote:
> On Sat, 12 Feb 2022 02:38:58 +0000, Nathan Smith <nathan-tech at hotmail.com>
> declaimed the following:
>
>
>> Two places it does not work:
>>
>> 1 In command line, it always puts the current directory at the end of
>> the execution of a command, eg
>>
>> dir:
>>
>> output
>>
>> c:/users/user/documents
>>
>> echo hi
>>
>> hi
>>
>> c:/users/user/documents
> 	Please cut&paste the actual text. Windows command shells use \ for path
> separators (the internal API doesn't care) -- and the prompt concludes with
> a > marker
>
> Microsoft Windows [Version 10.0.19041.1415]
> (c) Microsoft Corporation. All rights reserved.
>
> C:\Users\Wulfraed>echo help me
> help me
>
> C:\Users\Wulfraed>
>
>>
>> In my GUI that path does not always show, but I'm assuming that's just
>> because it doesn't throw in an extra empty blank line or some such?
>>
> 	The I/O system, when not connected to a terminal/console, typically
> doesn't flush the output until a new-line is emitted; it expects the next
> command to be input on the same "line" -- so the prompt may not be
> available on your line-oriented read operation.
>
>> More to the point though, if I run python from my gui, it just doesn't
>> show anything. No output, nothing. It's like it disconnects.
>>
>> Am I missing something?
>>
>> Even if the python command puts us into it's own command line, surely
>> subprocess's stdout and stderr should capture the output?
>>
> 	I believe it is possible for processes to "attach" to a "console" which
> is the window itself, not the default shell process within it. I
> hypothesize that stdin/stdout/stderr are tied to the process, not to the
> console.
>
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fwindows%2Fconsole%2Fattaching-to-a-console&data=04%7C01%7C%7C4d480ac0412c47bc861708d9ee504a23%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637802850884755366%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=S7q2xuq1uXp8U8UxEr2YaD09zzNPA304wuDPqb774Gw%3D&reserved=0
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fwindows%2Fconsole%2Fattachconsole&data=04%7C01%7C%7C4d480ac0412c47bc861708d9ee504a23%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637802850884755366%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=TMXuQmtispog86SWNth03doh%2BMKzgIGrhlAS4oRub18%3D&reserved=0
> """
> This function is primarily useful to applications that were linked with
> /SUBSYSTEM:WINDOWS, which implies to the operating system that a console is
> not needed before entering the program's main method. In that instance, the
> standard handles retrieved with GetStdHandle will likely be invalid on
> startup until AttachConsole is called. The exception to this is if the
> application is launched with handle inheritance by its parent process.
> """
> 	Yes -- normally sub-processes started from a console process do inherit
> the streams... but nothing says the sub-process has to use them <G>
>
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fwindows%2Fconsole%2Fallocconsole&data=04%7C01%7C%7C4d480ac0412c47bc861708d9ee504a23%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637802850884755366%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=ZcjzGw%2BJ9yp6XRWizoJYpQY0L%2FDvRPbVmUkW0Sx3N6k%3D&reserved=0
> """
> This function is primarily used by a graphical user interface (GUI)
> application to create a console window. GUI applications are initialized
> without a console. Console applications are initialized with a console,
> unless they are created as detached processes (by calling the CreateProcess
> function with the DETACHED_PROCESS flag).
> """
>
> 	Since running a "console" (*.py) script by double-clicking results in a
> console window being created to display output, I suspect the interpreter
> starts up in a "no console" mode, and then determines if it can attach or
> needs to allocate... "GUI" (*.pyw) scripts aren't supposed to have a
> console at all.
>
>
-- 

Best Wishes,

Nathan Smith, BSC


My Website: https://nathantech.net