gulam bug

gulam bug

Post by dennis pixt » Thu, 02 Aug 1990 19:39:00



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 bug

Post by Allan Pra » Thu, 02 Aug 1990 18:42:00



>I've noticed several problems with redirection in gulam (1.03.04.05) [...]
>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 then simply *rename* args.prg to shar.prg and run
>    shar a b > junk
>This time the output is to the screen [...]

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

 
 
 

gulam bug

Post by Neil Forsy » Thu, 02 Aug 1990 08:41:00



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.

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



+-----------------------------------------------------------------------------+
! 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"  !
+-----------------------------------------------------------------------------+
 
 
 

gulam bug

Post by Jwahar R. Bam » Thu, 02 Aug 1990 20:50:00



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

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

 
 
 

gulam bug

Post by Daniel A. Glass » Thu, 02 Aug 1990 15:51:00



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

 
 
 

gulam bug

Post by Neil Forsy » Sun, 02 Sep 1990 08:41:00



>Gulam has a serious bug in the code for launching programs.
> I happen to have the source, so I fixed this problem back in March,

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

gulam bug

Post by Allan Pra » Sun, 02 Sep 1990 19:17:00




>>Gulam has a serious bug in the code for launching programs.
>> I happen to have the source, so I fixed this problem back in March,
>Is there any chance you could post your less buggy version of Gulam to
>the net?
>! DISCLAIMER: Unless otherwise stated, the above comments are entirely my own !


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

 
 
 

1. Gulam bug? and turtle limitation.

I was hacking away and found that this gulam file crashed gulam.  Does
anyone have any ideas on how to do this.  

if -e $MAN_LIB$1.man
        more $MAN_LIB$1.man
ef
        echo No man entry for $1
endif

I can see the file and then as I exit the shell crashes with 2 or 3 bombs.

I have set MAN_LIB d:\man\ in gulam.g.

TURTLE does not back up a file that does not fit on a floppy.  This could
prove to be a severe limitation.  Has anyone hacked this or done anything
about this.

John Buchanan                     Dynamic Graphics Project
                                  Computer Systems Research Institute
                                  University of Toronto
(416) 978-6619                    Toronto, Ontario M5S 1A4



UUCP:           ...!mcvax!explorer.dgp.toronto.edu!juancho

--
=====================================================================
| Typical conversation on comp.[atari|amiga|mac].*                  |
=====================================================================
My watch is better than yours.  It has multitasking, windows and

2. permanent buffer-local variables

3. Fix bugs to fix bugs, or to Fix Bugs?

4. Diff. between G3 Rev.1 & 2?

5. Possible printing bug in Gulam

6. PROPOSAL: comp.sys.amiga.rebirth

7. GULAM beta (bug???)

8. Can I setup a sub-interface at cisco Gigabit Ethernet

9. Bug in VIEWER.APP & Gulam on Falcon

10. Bug in gulam alpha version - (nf)

11. gulam ls bug?

12. Bug in bets test Gulam

13. WARNING! Bug in Gulam v1.03