some problems for an introductory python test

[Chris Angelico]

On Thu, Aug 12, 2021 at 9:23 AM Dennis Lee Bieber <wlfraed at ix.netcom.com> wrote:
>
> On Thu, 12 Aug 2021 06:15:28 +1000, Chris Angelico <rosuav at gmail.com>
> declaimed the following:
>
>
> >The default command interpreter and shell on OS/2 was fairly primitive
> >by today's standards, and was highly compatible with the MS-DOS one,
> >but it also had the ability to run REXX scripts. REXX was *way* ahead
> >of its time. It's a shell language but remarkably well suited to
> >building GUIs and other tools (seriously, can you imagine designing a
> >GUI entirely in a bash script??). It had features that we'd consider
> >fairly normal or even primitive by Python's standards, but back then,
> >Python was extremely new and didn't really have very much mindshare.
> >REXX offered arbitrary-precision arithmetic, good databasing support,
> >a solid C API that made it easy to extend, integrations with a variety
> >of other systems... this was good stuff for its day. (REXX is still
> >around, but these days, I'd rather use Python.)
> >
>         I was spoiled by the Amiga variant of REXX. Most current
> implementations (well, Regina is the only one I've looked at) can just pass
> command to the default shell. The Amiga version took advantage of Intuition
> Message Ports (OS supported IPC). That allowed it to "address
> <application>" any application that defined an ARexx port, allowing ARexx
> to be used as a scripting language for that application (and with multiple
> applications, one could easily fetch data from app1 and feed it to app2).
> ARexx did not, to my memory, implement arbitrary precision math.

The same functionality was available in OS/2, but not heavily used.
You could 'address cmd commandname' to force something to be
interpreted as a shell command, but that was about it. However, I
built a MUD that used REXX as its scripting language, and the default
destination was sending text back to the person who sent the command;
and you could, of course, still 'address cmd' to run a shell command.

>         I've not seen anything equivalent in my light perusal of the Win32 API
> (the various guide books aren't layed out in any way to be a reference),
> and Linux seems to use UNIX sockets for IPC... No way to search for a
> connection point by name...
>

Win32 doesn't really have it. Unix sockets are kinda there but you
identify something by a path to the socket, not the name of the
application. But I think dbus is probably the closest to what you're
thinking of.

ChrisA