[Tutor] What am I missing here?

[Dennis Lee Bieber]

On Sun, 13 Feb 2022 02:17:14 +0000, Nathan Smith <nathan-tech at hotmail.com>
declaimed the following:

>
>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.
>
	Take into account that this was all hypothesis on my part. I've never
coded something using that level of Win32.


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

	Again, hypothesis... One would have to study the Python start-up code
for Windows to see what it is doing with the I/O.

	If you really want to get perplexed, open a command shell and enter:

start /b python

(normally "start" will open a new console if the application is not a
windowed program; /b prevents the new console).

	My experiment showed that Python was seeing 1 character for each line
of input and CMD shell was seeing the rest.

>
>Is there a work around for this?
>

	I don't know of one, off hand. It's a partial problem (in my mind) of
how subprocess communication works in Python (and the various OSs*). The
only system I ever encountered that got close to what you are trying to do
was the Commodore Amiga with ARexx. I don't know of Regina on Windows can
duplicate it for this.

	A language feature of Rexx (ARexx was an Amiga port, and Regina is a
generalized port) is the ADDRESS statement which is used to specify a
"command interpreter" to be used by anything in the Rexx script that is NOT
parsed as a Rexx statement. Such statements would be evaluated (variable
substitutions made) and then sent directly to the "command interpreter" for
processing. Special variables would capture returns from the external
processing. On the Amiga, any program that "opened a RexxPort" could be
specified as the command interpreter (so with proper switching of "command
interpreter" one could send word processor commands to one process to, say,
select and copy a paragraph, and then switch to a desktop publishing
program to paste that paragraph). Regina basically just has a standard
shell as the target (or no shell -- direct execution).


>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.

	Unfortunately, I suspect the spawning of an interactive process may be
a hindrance (have you tried with other interactive command line programs?
Pity M$ never updated EDIT or EDLIN for 64-bit OS; they'd be ideal. I have
the impression all your other tests have been one-shot shell commands --
like "echo" -- that don't really do interaction)

	Oh, one thing...

C:\Users\Wulfraed>python /?
usage: python [option] ... [-c cmd | -m mod | file | -] [arg] ...
Options and arguments (and corresponding environment variables):
-b     : issue warnings about str(bytes_instance), str(bytearray_instance)
         and comparing bytes/bytearray with str. (-bb: issue errors)

<SNIP>

-u     : force the stdout and stderr streams to be unbuffered;
         this option has no effect on stdin; also PYTHONUNBUFFERED=x

<SNIP>

	Instead of just issuing "python", try "python -u"


*	I've only seen two operating systems that supported a simple means of
ad-hoc interprocess communication. Everything else seems to rely on things
like TCP/UDP sockets, or named pipes.
	The Amiga: the whole OS was based upon passing messages via message
ports (basically linked lists -- posting a message would add your message
structure to the end of a linked list, the target process would read
messages from the list, do stuff, and send a reply back [the message
structure included data on what port to send replies]). This was pretty
much a no-cost operation as all memory was shared by processes (which is
also the downfall of the OS -- to use protected memory would mean message
passing would have to trigger supervisor mode, so the message memory could
be unmapped from source and mapped to target).
	VAX/VMS (OpenVMS): supported things called mailboxes -- which are NOT
like mailboxes in real-time OSs. One would send messages to "named"
mailboxes and other processes could read from those mailboxes (obviously
this scheme goes through supervisor levels for memory mapping. Unlike Amiga
ports, which are readable only by the port creator, mailboxes are shared
reader/writer systems.


-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
	wlfraed at ix.netcom.com    http://wlfraed.microdiversity.freeddns.org/