[Tutor] What am I missing here?

[Nathan Smith]

Heya,


thanks for your response.

Admittedly, a bit of a shame as from what you've mentioned, and from 
research I've done that supports it, it does seem like this proof of 
concept was a bit of a bust. Well, sort of anyway.

the command prompt side of things works, but the second you hand off to 
interactive shells, bust. And not only bust but stuck bust so you can't 
even back out of it.

It's true I could write in an exception something like...

if(line==">>>"):

  # we're in the python console

  handle.stdin.write("exit")

  # some code here to send control z, I think winpexpect actually has a 
function for that

  # tell the user that interactive shells are not supported


Which is fine for python, but would not be a catch all for any other 
interactive shell out there that may do things in a similar way, I'm 
thinking of gdb for instance (though is there a windows gdb?)


On a side note of this not being a *complete* bust, I could do a 
separate program for running the python interactive shell by wrapping 
something around eval, right?

Eval can be dangerous because you can literally execute anything but, in 
the case of a shell wrapper, that's kind of the point because it's the 
same as running the python command anyway?


In that light though I have a new question. How would I go about running 
something that was multiple lines?

It's a bit of reinventing the wheel but if the user enters:

for x in range(10):

  print(x)


How would I hand that off to eval? Putting:

eval("for x in range(10): \n print(x)") throws me a syntax error.


Best

Nathan

On 13/02/2022 04:13, Dennis Lee Bieber wrote:
> 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.
>
>
-- 

Best Wishes,

Nathan Smith, BSC


My Website: https://nathantech.net