Re: Using printf() in a 4gl program w/C

Path: emory!att!cbnewsm!jonesie From: jonesie@cbnewsm.att.com (The Bohemian Welshman) Newsgroups: comp.databases.informix Message-ID: <1992Jan31.021630.13494@cbnewsm.att.com> Date: 31 Jan 92 02:16:30 GMT References: <1992Jan28.215456.3789@kodak.kodak.com> <1992Jan30.000533.25067@cbnewsm.att.com> <1992Jan30.111017.541@halexv.uucp> Organization: AT&T, Columbus, Ohio In response to the question about no CR following NL using stdio calls from C, I wrote: >> Try calling the following routine, or something like it, before >>using the stdio calls. [Source for function omitted] Gregory Hogg reminds us: > Might be a good idea to save the tty state before you do the >ioctl and restore it after you finish printing before returning to >the 4GL program. That way all tty modes will be as they where before >you changed them. Yep, always put things back the way you found them. In other circumstances, I would strongly agree. [I generally swear by Henry Spencers 10 commandments for 'C', for example.] However, it seems that 4GL executables set the tty modes the way it wants them before *every* i/o call! I would need the source to the libs to be sure, of course, so this is "black-box" supposition, but it seems that 4GL generated code saves the tty state when it starts, restores it when the program gracefully terminates, and plays very freely with the modes in between. [You may have noticed that core dumps often leave the tty modes messed up.] The 4GL generated code seems to clear OCRNL before each i/o to/from a form and set OCRNL before each non-form i/o. And it may well make sense for the 4GL generated code to just set the modes the way it wants them before each "chunk" of i/o, rather than attempting to track and then depend on the "current" tty states. You sure never have any problems associated improper tty modes. So I don't bother resetting the tty modes in 4GL projects anymore. I've never found it made any difference. -- Chuck Jones cej@ccsitn.att.com Just me, not AT&T