Very Computer

I've noticed several problems with redirection in gulam (1.03.04.05) -- most
recently with shar and ssed.  I finally narrowed it down to the following
situation.

I wrote a trivial program, args.prg (compiled with mwc) to dump out its
args, the environment, and whether the file handles are ttys.  When I run

        args a b > junk

I get the output in junk: arg[0] through arg[2] are "args", "a", and "b"; and
handle 1 is not a tty.  I then simply *rename* args.prg to shar.prg and run

        shar a b > junk

This time the output is to the screen: arg[0] to arg[4] are "shar", "a",
"b", ">", and "junk"; and handle 1 is a tty.  I checked that there is not
another "shar" in my path, and that env_type is set to "mw".

The same thing happens if I rename args.prg to ssed.prg, but if I rename it
to (for example) sed.prg then the redirection is correct.  The problem
doesn't happen if I use msh instead of gulam.

Does anyone know what is happening??  And is there any possibility of an
upgrade to gulam??

--
Dennis Pixton
Department of Mathematical Sciences     (607) 777-4239

Gulam has a serious bug in the code for launching programs.  There is a
table of the internal commands, and flags telling how to handle the
argument list for each.  Gulam looks your input up in this table, and,
in the case of an external command, won't find a match.  However, the
flags of the last internal command it looked at will be used to
parse your arguments!  Some flags mean "Don't expand wildcards" and
others mean "don't do anything."  I happen to have the source,
so I fixed this problem back in March, but I don't know if the
official types have noticed the bug yet.

There are other bugs in redirection, notably when you use shell_p to
exec a program and redirect its output.  Gulam is the shell I hate to
love: it's too good to throw out, and yet so bad in some ways.

============================================
Opinions expressed above do not necessarily     -- Allan Pratt, Atari Corp.
reflect those of Atari Corp. or anyone else.      ...ames!atari!apratt

Quote:>I've noticed several problems with redirection in gulam (1.03.04.05)

I'm not sure if the problem is (or entirely) with Gulam.

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.

I personally use Gulam all the time and would welcome an upgrade too.

+-----------------------------------------------------------------------------+
! DISCLAIMER: Unless otherwise stated, the above comments are entirely my own !
!                                                                             !


! Heriot-Watt University             UUCP:   ..!ukc!cs.hw.ac.uk!neil          !
! Edinburgh, Scotland, UK            "spam spaM spAM sPAM SPAM, lovely SPAM"  !
+-----------------------------------------------------------------------------+

i am posting this here instead of replying by mail as i suspect quite a
few people may have run into this.

        try
                shar a b >junk
                        ^^^  notice no space between '>' and 'junk'

instead. This is a bug in some versions of Gulam.
bang:   {any internet host}!dsrgsun.ces.CWRU.edu!bammi  jwahar r. bammi

GEnie:  J.Bammi

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-----------

Is there any chance you could post your less buggy version of Gulam to
the net?

Quote:>============================================
>Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp.
>reflect those of Atari Corp. or anyone else.          ...ames!atari!apratt

+-----------------------------------------------------------------------------+
! DISCLAIMER: Unless otherwise stated, the above comments are entirely my own !
!                                                                             !
! "I think all right thinking people in this country are sick and tired of    !
! being told that ordinary decent people are fed up in this country with      !
! being sick and tired. I'm certainly not and I'm sick and tired of being     !
! told that I am!" - Monty Python                                             !
!                                                                             !


! Heriot-Watt University             UUCP:   ..!ukc!cs.hw.ac.uk!neil          !
! Edinburgh, Scotland, UK                                                     !
+-----------------------------------------------------------------------------+

Well, actually, no.  Just because Bammi and friends were kind enough to
send me the source (I forget now exactly how I came to have it) doesn't
mean I can distribute hacked versions.  Sorry.  Ask them for an update,
and hope it's a major one - there are some SERIOUS and fundamental
flaws in places like directory handling (ever say "ls -lt" on a
directory with 100 entries?) and memory management (leave the editor,
get bombs, see Desktop).

============================================
Opinions expressed above do not necessarily     -- Allan Pratt, Atari Corp.
reflect those of Atari Corp. or anyone else.      ...ames!atari!apratt