jeff@softop.UUCP (Jeff) (05/02/89)
Ok, all you wizards, please explain what is happening here. The following function extract are from a program I wrote to take input from a file and feed it to an executable shell a line at a time. This involves going into raw mode, obtaining a function key that determines what action to take with the command buffers, and then returning to cooked mode to execute the command. ..... static struct termio tbufcooked; static struct termio tbufraw; ... void set_cooked() { (void) ioctl( 0, TCSETAF, &tbufcooked ); } ... void set_raw() { (void) ioctl( 0, TCSETAF, &tbufraw ); } ... void init_raw() { (void) ioctl( 0, TCGETA, &tbufraw ); tbufcooked = tbufraw; tbufraw.c_iflag &= ~(INLCR | ICRNL | IUCLC | ISTRIP | IXON | BRKINT ); /* * recommended by GP - seems to work with this removed!! * tbufraw.c_oflag &= ~OPOST; */ tbufraw.c_lflag &= ~(ICANON | ISIG | ECHO ); tbufraw.c_cc[4] = 1; tbufraw.c_cc[5] = 10; } The bizarre problem occurs with OPOST. If I toggle OPOST, then after the retrun to cooked the output from the sub-shell does the normal trick of heading rapidly for the right marginand piling up there. With OPOST untouched all works well. My question is WHY??? Why does saving, toggling, and then restoring OPOST not act the same as ignoring OPOST in the first place. I am running XENIX 2.3 i80286 Thanks muchly for suggestions. I have the program working, but I am still poozled. -- ---------------------------------------------------------------------------- | Jeff Tate | 2425 Pandora Street, Vancouver, BC, Canada | | van-bc!softop!jeff | (604) 254-4583 | ----------------------------------------------------------------------------