Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!uwvax!per2!dag From: dag@per2.UUCP (Daniel A. Glasser) Newsgroups: comp.sys.atari.st Subject: Re: gulam bug Summary: This sounds VERY fishy... Message-ID: <878@per2.UUCP> Date: 28 Aug 89 14:51:43 GMT References: <3030@brahma.cs.hw.ac.uk> Organization: Persoft Inc., Madison, WI Lines: 45 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-----------