braner@batcomputer.TN.CORNELL.EDU (braner) (08/25/86)
[] Of greater annoyance to me is the fact that Megamax-compiled programs crash if IO is redirected from inside Micro C-Shell. The SAME program works fine if named PROG.TTP and invoked from the desktop, entering ">OUTFILE" into the dialog box. This is an old problem, but I havn't heard from either company yet. (I don't know if it's Megamax or Beckemeyer's "fault"). Contrary to recent claims, it does not matter (from C-Shell) if I use ">outfile" or "> outfile". It never works - I get two balls with lighted fuses. Any solutions? Are the companies involved going to do something about it? The products (Micro C-Shell and Megamax C dev. system) are generally excellent, and sales of both would gain if they'd work together better. - Moshe Braner Corson Hall, Cornell Univ., Ithaca NY 14853 (607) 272-3487
gert@nikhefh.uucp (Gert Poletiek) (08/26/86)
In article <942@batcomputer.TN.CORNELL.EDU> braner@batcomputer.UUCP (braner) writes: >[] > >Of greater annoyance to me is the fact that Megamax-compiled programs >crash if IO is redirected from inside Micro C-Shell. The SAME >program works fine if named PROG.TTP and invoked from the desktop, >entering ">OUTFILE" into the dialog box. This is an old problem, >but I havn't heard from either company yet. (I don't know if it's >Megamax or Beckemeyer's "fault"). Contrary to recent claims, it does >not matter (from C-Shell) if I use ">outfile" or "> outfile". >It never works - I get two balls with lighted fuses. > >Any solutions? Are the companies involved going to do something >about it? The products (Micro C-Shell and Megamax C dev. system) >are generally excellent, and sales of both would gain if they'd >work together better. > >- Moshe Braner > >Corson Hall, Cornell Univ., Ithaca NY 14853 (607) 272-3487 The fault is with Megamax, not Beckemeyer. Its even more strange because Magamax manuals frequently refer to the Beckemeyer shell as an alternative to their useless 'graphic shell'; an even worse imitation of the Gem Desktop. What happens is the following. The Megamax compiler treats the function main as a special case, and if it sees any arguments in its function header, it generates a reference to an external label called _initargcv. If no argumenents to main are found, then the compiler generates a global label _initargcv in the module containing main, and it consists only of an RTS instruction. So the problem arises in the _initargcv in the SYSLIB library. What _initargcv does is the following: It initializes the argv, argc variables (At Megamax they sure don't read the GemDos manuals: they don't initialize the **envp pointer). When the _initargcv routine comes across an argument line token starting with '>' , '<' or '>>' they do their own crazy i/o redirection. The i/o redirection in Megamax works as followes: Megamax probably didn't like GemDos' not opening a standard error file, and therefor desided to do it themselves. GemDos DOES open standard input and output though, even the filedescriptor numbers of those two files are the same as in unix, (0 and 1), but the filedescriptor 2 is missing (that one refers to the RS232 port, Sigh). If you write a short program with Megamax that prints out the filedescriptor numbers of stdin,out and err, you will see the following numbers appear on the screen: -32000 -32000 -32000 Now every time you do a read or a write your filedescriptor is compared with -32000 (SPEED!!!). _Initargcv will substitute the -32000 with a REAL gemdos file descriptor if the commandline from the DESKTOP (not the Beckemeyer shell) contains one of the redirection characters. I came across this bug when writing my own C-shell, that does the io redirection BEFORE the commandline is passed to the program called. I do the i/o redirection with the gemdos equivalents of the UNIX systecalls dup and dup2, the same way i think as the Beckemeyer shell does the io redirection. Shortly I will post the follwing to this newsgroup: - Newly coded _initargcv to accomplish REAL io redirection, at the price of loss of the standard error channel. - Code to catch the Gemdos kill character (^C), which is less trivial because Megamax produces position independent code. - A prerelease of my idea of a handy C-shell like command interpreter, (in about a month from now) that will include (at least) the follwing features: - real io redirection - shell script execution (batch.ttp can be thrown away), including parameter passing to shell scripts. - aliasing - shell variables - history mechanism - real UNIX pathnames (as the backslash will be the escape character) -Commands: alias define a shorthand cat list a file cd change working directory chmod change file flags clear clear the screen cmp compare files cp [-f] copy a file date get / set date and time df show free space on drive diff get file differences echo [-n] print arguments history see previous commands logout exit from GP-shell lpr send to line printer ls [-lt] show files mkdir create a directory more list a file mv [-f] rename or move a file od [-coh] dump file pwd working directory name read read variable rm [-i] delete file rmdir [-i] delete a directory set set/show shell variable touch update file time & date unalias undefine a shorthand unset clear shell variable - internal variables: color to set the screen color (now black or white) blink set the cursor blink rate delay set initial keyboard delay repeat set keyboard repeat speed path search path home home directory prompt your personal prompt ignoreeof control-D acceptance as logout (the first four vars will render the control panel useless) If anybody has additional ideas for commands and the like, tell me, and i will include it. (This shell is not a port of any existing shell, and was written for the ST in the first place) Gert Poletiek Dutch National Institute for High Energy Physics Amsterdam The Netherlands
turner@imagen.UUCP (D'arc Angel) (08/26/86)
> Summary: Still unresolved > > [] > > Of greater annoyance to me is the fact that Megamax-compiled programs > crash if IO is redirected from inside Micro C-Shell. The SAME > program works fine if named PROG.TTP and invoked from the desktop, > entering ">OUTFILE" into the dialog box. This is an old problem, > but I havn't heard from either company yet. (I don't know if it's > Megamax or Beckemeyer's "fault"). Contrary to recent claims, it does > not matter (from C-Shell) if I use ">outfile" or "> outfile". > It never works - I get two balls with lighted fuses. > its a megamax C problem, uCsh is using the Force call to 'steal' i/o handle 1 (stdout) and force it to a file, this works fine as long as the 'redirected' program only uses Fwrite to do the output. sadly the printf routine in megamax C does not, hence the the 2 bombs. the worst news is that there is no fix for it (except from Megamax hint...hint...) i had to leave redirection out of uEmacs 3.7 because of it. i spoke to some people at atari about this and they were not sure that DRI C's printf would fare any better. -- ---- It aint life that gets me down, it's gravity Name: James M. Turner Mail: Imagen Corp. 2650 San Tomas Expressway, P.O. Box 58101 Santa Clara, CA 95052-8101 AT&T: (408) 986-9400 UUCP: ...{decvax,ucbvax}!decwrl!imagen!turner CompuServe: 76327,1575 GEnie : D-ARCANGEL