andy@sdcarl.UUCP (Andrew Voelkel) (07/23/85)
I am considering the possibility of writing some subset of what looks like
a unix "shell" (really just a history mechanism to cut down on repeated
long command lines), since queries as to the existence of such a facility
have been unsuccessfull. I have read the description of the dos EXEC call
in the tech reference manual and in Norton's "programmers guide". I'm
still a bit confused and remember some discussion about the subject a
while back. Could someone help me out with a more thourough description,
and maybe an example of use? Are there tragic flaws to prevent such a
scheme from working at all? I figure there must be stumbling blocks or
someone would have succeeded at doing something like this already.
Another question:
I am using the Mark Williams C compiler to port software written
under Unix. They often read binary input from stdin. Such input is often
cut off in the middle of a file (presumably because we run into a end of
file character). Friends have run into this problem also. Is it really
true that one cannot read binary input from stdin (a file), or is this
a problem unique to the Mark Williams Compiler?
Thanks in advance to any answers?
--
Andrew Voelkel
{ucbvax,ihnp4,akgua,hplabs,sdcsvax}!sdcarl!andybc@cyb-eng.UUCP (Bill Crews) (07/29/85)
> I am considering the possibility of writing some subset of what looks like > a unix "shell" (really just a history mechanism to cut down on repeated > long command lines), since queries as to the existence of such a facility > have been unsuccessfull. I have read the description of the dos EXEC call > in the tech reference manual and in Norton's "programmers guide". I'm > still a bit confused and remember some discussion about the subject a > while back. Could someone help me out with a more thourough description, > and maybe an example of use? Are there tragic flaws to prevent such a > scheme from working at all? I figure there must be stumbling blocks or > someone would have succeeded at doing something like this already. I don't have time to tell you *all* about it, but it does work, and a Unix- like subshell is certainly do-able. Just remember that the stack is totally bombed upon return from the exec call! > Another question: > I am using the Mark Williams C compiler to port software written > under Unix. They often read binary input from stdin. Such input is often > cut off in the middle of a file (presumably because we run into a end of > file character). Friends have run into this problem also. Is it really > true that one cannot read binary input from stdin (a file), or is this > a problem unique to the Mark Williams Compiler? Use the ioctl call (int 21h, ah = 44h) to set the "binary" bit. Remember to set it back. -- / \ Bill Crews ( bc ) Cyb Systems, Inc \__/ Austin, Texas [ gatech | ihnp4 | nbires | seismo | ucb-vax ] ! ut-sally ! cyb-eng ! bc
cramer@kontron.UUCP (Clayton Cramer) (07/29/85)
> I am considering the possibility of writing some subset of what looks like > a unix "shell" (really just a history mechanism to cut down on repeated > long command lines), since queries as to the existence of such a facility > have been unsuccessfull. I have read the description of the dos EXEC call > in the tech reference manual and in Norton's "programmers guide". I'm > still a bit confused and remember some discussion about the subject a > while back. Could someone help me out with a more thourough description, > and maybe an example of use? Are there tragic flaws to prevent such a > scheme from working at all? I figure there must be stumbling blocks or > someone would have succeeded at doing something like this already. > I built a history mechanism in BASIC (!) a little while back for the AT using BASIC's shell command. I never got it completely working (limitations of BASIC, and I don't use the AT enough to justify writing it in C), but I will try to dig up the code and post it to this group sometime this week; it may be of use as an example, or you might want to finish debugging it! > Another question: > I am using the Mark Williams C compiler to port software written > under Unix. They often read binary input from stdin. Such input is often > cut off in the middle of a file (presumably because we run into a end of > file character). Friends have run into this problem also. Is it really > true that one cannot read binary input from stdin (a file), or is this > a problem unique to the Mark Williams Compiler? > Don't know about the Mark Williams C compiler, but a lot of C compilers I have played with for the PC are inadequate or wrong when it comes to binary input from stdin. Aztec C from Manx, in particular, has one very severe bug which prevents you from correctly reading any of the keystrokes which generate 00 xx for a value. Microsoft C V3.0 works perfectly for binary file input from stdin. > Thanks in advance to any answers? > > > -- > Andrew Voelkel > {ucbvax,ihnp4,akgua,hplabs,sdcsvax}!sdcarl!andy
peter@kitty.UUCP (Peter DaSilva) (08/01/85)
> like subshell is certainly do-able. Just remember that the stack is totally > bombed upon return from the exec call! Funny. I use it all the time & there's nothing wrong with the stack. Or does Lattice 'C's runtime library fix that?