Read/Write from/to a process

Mike Meyer mwm at mired.org
Tue Oct 25 22:13:43 CEST 2005


Dennis Lee Bieber <wlfraed at ix.netcom.com> writes:
> 	Followed by the Amiga... The Amiga IPC used "message ports" (linked
> lists owned by the creating process to which, if "public" [named], other
> processes could send message packets). The Amiga port of REXX made use
> of message ports as its native IPC...
>
> address SOME_APPLICATION
>
> would redirect all "non-REXX" statements to the message port named
> "SOME_APPLICATION"; the default being "address COMMAND" -- a shell
> interpreter. Then, any non-REXX statement would be processed by the
> shell interpreter -- and the easiest way to force a non-REXX statement
> was to put a quote mark around it (or the first word of it)
>
> "delete" my_file_var
>
> would translate my_file_var to whatever had been assigned to it earlier,
> and pass a delete command to the shell.
>
> address ED
>
> would now route such statements to the "ed" editor

These things weren't unique to the Amiga port of Rexx. Rexx on VM/CMS
did all these things. Tying them to the native IPC mechanism as a
brilliant move. Add in the shared library for supporting Rexx so that
adding Rexx support to an application (or to a language!) was trivial,
and Rexx the end result was that Rexx was used far more heavily on the
Amiga than on VM/CMS.

The downside was that variables had a default value of their name in
upper case, and any statement that wasn't recognized evaluated as a
string expresion and then fed to the current command processor. So
that the quote marks weren't needed - if you hadn't assigned a value
to the variable delete, then you could just do

   delete my_file_var

and it would do the right thing. Of course, almost anything you typed
like that was valid, creating interesting bugs. I made it a habit to
keep "0" and "1" commands around that just logged errors, as those
would catch such things.

      <mike
-- 
Mike Meyer <mwm at mired.org>			http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.



More information about the Python-list mailing list