At process startup, YottaDB currently changes a few terminal characteristics
if the principal device is a terminal. But if a C program that invokes a call-in is
how the YottaDB initialization occurred, process exit currently does not reset these
characteristics. This leaves the terminal in a weird state. For example, character
echo is disabled etc. A "stty sane" is needed to get the terminal back to normal.
This is an issue in GT.M and is reported at https://sourceforge.net/p/fis-gtm/bugs/60/.
The terminal changes are actually needed in case a READ or WRITE from/to the terminal
(including direct mode) happens. But this is done unconditionally. This is best avoided.
The fixes are
Fix io_rundown to do a resetterm() in case process is exiting and we do not do a close
of the terminal device (due to caller invoking this with RUNDOWN_EXCEPT_STD.
Do not do setterm() at iott_open() time. Instead defer it as much as possible.
Invoke setterm() at various points (iott_rdone.c, iott_readfl.c, iott_write.c)
to do the terminal characteristics changes using the new SETTERM_IF_NEEDED macro.
setterm() is changed to check if the changes have already been done and if so
return right away. Similar changes are done to resetterm(). A pid is stored in
the new field tt_ptr->setterm_done_by (instead of a boolean value) to identify in
case of ojstartchild() whether the child or the parent did the setterm() (and hence
needs to do the resetterm()). op_zedit() and op_zsystem() are fixed to do the right
checks (new macro IS_SETTERM_DONE) for whether a setterm()/resetterm() are needed.
continue_handler() did a setterm() which seemed incorrect so that has been removed.
There are two issues.
At process startup, YottaDB currently changes a few terminal characteristics if the principal device is a terminal. But if a C program that invokes a call-in is how the YottaDB initialization occurred, process exit currently does not reset these characteristics. This leaves the terminal in a weird state. For example, character echo is disabled etc. A "stty sane" is needed to get the terminal back to normal. This is an issue in GT.M and is reported at https://sourceforge.net/p/fis-gtm/bugs/60/.
The terminal changes are actually needed in case a READ or WRITE from/to the terminal (including direct mode) happens. But this is done unconditionally. This is best avoided.
The fixes are
Fix io_rundown to do a resetterm() in case process is exiting and we do not do a close of the terminal device (due to caller invoking this with RUNDOWN_EXCEPT_STD.
Do not do setterm() at iott_open() time. Instead defer it as much as possible. Invoke setterm() at various points (iott_rdone.c, iott_readfl.c, iott_write.c) to do the terminal characteristics changes using the new SETTERM_IF_NEEDED macro. setterm() is changed to check if the changes have already been done and if so return right away. Similar changes are done to resetterm(). A pid is stored in the new field tt_ptr->setterm_done_by (instead of a boolean value) to identify in case of ojstartchild() whether the child or the parent did the setterm() (and hence needs to do the resetterm()). op_zedit() and op_zsystem() are fixed to do the right checks (new macro IS_SETTERM_DONE) for whether a setterm()/resetterm() are needed. continue_handler() did a setterm() which seemed incorrect so that has been removed.