🚀 go-pugleaf

In article <3030@brahma.cs.hw.ac.uk>, neil@cs.hw.ac.uk (Neil Forsyth) writes:
> I compiled a trivial program that would read from stdin and print to both
> stdout and stderr. First I compiled it under Sozobon using DLibs.
> It worked fine. I then used redirection for both input and output. Only the
> message sent to stderr appeared. Again no problem. BUT when I compiled it
> with MWCthere was no screen output and the stderr was appended to the input
> file!! On both occasions I was using Gulam. If a program compiled with MWC
> expects only to be run from 'msh' then I think that is a lose.

That last line is implying something about MWC which is unfounded and untrue.
I believe that the ONLY C compiler released for the ST which required its own
shell to spawn it was Hippo, and that is LONG DEAD!

The behavior described above sounds more than a little fishy.  Are you SURE
that the only difference in the two runs with redirection were in the compiler
used?

I am not sure of the runtime startup and standard I/O routines in dLibs, but I
am intemately familliar with MWC's runtime code.  MWC's stderr output is written
to the GEM standard file handle for AUX.  The normal runtime startup forces
this handle to the console when it does not detect the "ARGV=" string in its
environment.  If the ARGV string is found, and it is of the correct format,
the standard handles are assumed to be correct for STDERR, STDOUT and STDIN.
To append to the input file something must have opened the input file for
read/write or write access and seeked to the end of the file BEFORE the MWC
program was exec'ed.

Programs compiled with MWC expect to be run from just about any environment,
but expect certain conventions to be followed.  If they are not followed and
this is detected, the runtime startup assumes nothing about the environment.
If the conventions are almost followed, but not quite, some things might go
wrong.  The MWC conventions have been around, in use, and documented longer
than dLibs or gulaam.  They may not be ideal, but nothing significantly
better has been presented (that I'm aware of.)

I've been doing software development in various environments for over eight
years now.  I've been doing development on the ST for almost four years.
In this time, I've learned to investigate what a bug is doing before pointing
fingers.  I feel like getting onto a soap box and preaching to the masses
about bug isolation and identification, but I'm going to stop myself...
-- 
 _____________________________________________________________________________
    Daniel A. Glasser                           One of those things that goes
    uwvax!per2!dag                              "BUMP!!!(ouch)" in the night. 
 ---Persoft, Inc.---------465 Science Drive-------Madison, WI 53711-----------