dennis@marge.math.binghamton.edu (dennis pixton) (08/23/89)
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 SUNY-Binghamton dennis@math.binghamton.edu Binghamton, NY 13901 dpixton@bingvaxa.bitnet
apratt@atari.UUCP (Allan Pratt) (08/24/89)
dennis@marge.math.binghamton.edu (dennis pixton) writes: >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
neil@cs.hw.ac.uk (Neil Forsyth) (08/24/89)
In article <DENNIS.89Aug22143938@marge.math.binghamton.edu> dennis@marge.math.binghamton.edu (dennis pixton) writes: >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 >SUNY-Binghamton dennis@math.binghamton.edu >Binghamton, NY 13901 dpixton@bingvaxa.bitnet +-----------------------------------------------------------------------------+ ! DISCLAIMER: Unless otherwise stated, the above comments are entirely my own ! ! ! ! Neil Forsyth JANET: neil@uk.ac.hw.cs ! ! Dept. of Computer Science ARPA: neil@cs.hw.ac.uk ! ! Heriot-Watt University UUCP: ..!ukc!cs.hw.ac.uk!neil ! ! Edinburgh, Scotland, UK "spam spaM spAM sPAM SPAM, lovely SPAM" ! +-----------------------------------------------------------------------------+
bammi@dsrgsun.ces.cwru.edu (Jwahar R. Bammi) (08/25/89)
In article <DENNIS.89Aug22143938@marge.math.binghamton.edu>, dennis@marge (dennis pixton) writes: > 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 domain: bammi@dsrgsun.ces.CWRU.edu GEnie: J.Bammi
dag@per2.UUCP (Daniel A. Glasser) (08/28/89)
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-----------
neil@cs.hw.ac.uk (Neil Forsyth) (09/01/89)
In article <1658@atari.UUCP> apratt@atari.UUCP (Allan Pratt) writes: >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? >============================================ >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 ! ! ! ! Neil Forsyth JANET: neil@uk.ac.hw.cs ! ! Dept. of Computer Science ARPA: neil@cs.hw.ac.uk ! ! Heriot-Watt University UUCP: ..!ukc!cs.hw.ac.uk!neil ! ! Edinburgh, Scotland, UK ! +-----------------------------------------------------------------------------+
apratt@atari.UUCP (Allan Pratt) (09/07/89)
neil@cs.hw.ac.uk (Neil Forsyth) writes: >In article <1658@atari.UUCP> apratt@atari.UUCP (Allan Pratt) writes: >>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 ! >! Neil Forsyth JANET: neil@uk.ac.hw.cs ! 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