[Coco] Broken Syntax (Was: Weird errors)

[Willard Goosey]

>Date: Tue, 12 Sep 2006 14:33:18 -0500
>From: Joel Ewy <jcewy at swbell.net>
>
>Another way to think about it is that hard coding the syntax of a
>particular utility in a binary perhaps doesn't completely embody the
>OS-9 toolbox philosophy.  

Perhaps, but there's also the OS-9 keep-it-small philosophy, the
natural result of running a multitasking OS in 64K RAM with a 160K
disk. ;-)

Remember, for the most part we're talking about ten to twenty year old
software.

And part of the toolbox philosophy, to me, is "don't write it yourself
if someone else has already done it for you."  

This used to be a core part of UNIX philosphy.  I admit UNIX grew away
from this philosophy as it got big, but even now, lots of programs
will fork off stty(1) instead of poking at the IOCTLs themselves.

CS professors will tell you that code reuse is a good thing, rather
the reused code is in a shared library or a collection of stand-alone
utilities.

For instance, I once wrote a utility under OS-9 to check rather /term
was a windint window or a vdg screen.  It worked by forking "ident -m
term" and reading ident's stdout.  Sure, it might have been a more
educational excercise to link the term module into my memory space and
rummage through it by hand, but I was working on a larger project and
needed a small tool, quickly.

>Perhaps it's a forgivable expediency and may improve performance
>somewhat over reading the syntax from a configuration file.

I have to admit, that's an interesting idea.

>But my opinion would be that if you need to mess around with system
>utilities, you probably should be wrapping the binary in a shell
>script, which is easily editable.

Shell scripts can be a little odd under OS-9.  They work fine when
called from the shell, or from a program that calls the shell
(system() or BASIC-09 SHELL) but fail utterly when called by F$Fork.
GShell, for instance, doesn't know what to do with shell scripts.  

The older shells also had, I believe, very limited argument passing.

Due to these limitations, BASIC-09 binaries get made where a UNIX
shell script would have been sufficient.

We don't have BASH, ya know. ;-)  I'm not complaining about Shell+
here, it has become a very good little shell.  

>Hard coding such details in the BASIC-09 program module seems a
>little ham-fisted to me.

My understanding is that Microware warned that drivers and system
calls might change, but that they would keep the utility syntax the
same.  

And ham-fisted or not, it was/is the accepted programing style.  Look
through old RAINBOWs or the BASIC-09 Tour Guide.  They're full of
SHELL"this", SHELL"that", SHELL"Anything-you-cant-RUN" :-)

>As I think about it more, why is BASIC-09 (is it the runb module we're
>talking about here?) calling tmode in the first place, 

Actually, it's the mainline user module calling tmode.  runb neither
knows or cares about the terminal status.

One of the programs I've had this tmode problem with is stevie, a VI
clone written in C and ported over to OS-9.  It's not just a BASIC09
thing.  

>instead of just doing an appropriate setstat?

Why waste precious memory on code that's only going to be run once,
can be run outside your memory space (under LII), is harder to get
right (information hiding and abstraction), and has already been done,
anyway? (laziness:)

>Why should it assume there is a tmode utility available at all? 

It's part of the standard distribution. 

>I wouldn't be too hard on Boisy here.  I think BASIC-09 is at fault.

So, are you volunteering to port BASH to OS-9?  Or how about Python?
(ASH may be a feasible port, but I think BASH's executable is more than
64K...:)  I really would love to see more programming languages under
OS-9.  APL, pilot, and forth are just too strange. 

Willard
-- 
Willard Goosey  goosey at sdc.org
Socorro, New Mexico, USA
"I've never been to Contempt!  Isn't that somewhere in New Mexico?"
   --- Yacko