> Do shells really? A simple case of the opposite: start vim, kill -9
> from another shell, and you have to type "stty sane". I think it is
> more up to the application to save and restore.
That's true. What I meant, however, was the handling of terminal I/O and
the 'stop' signal in processes spawned by this shell.
When you invoke 'vim' in PicoLisp, it behaves correctly: Terminal I/O
obviously works (as you can edit in 'vim'), and if you hit Ctrl-Z 'vim'
is stopped and control is back at PicoLisp (i.e. our "shell"). You are
now in PicoLisp at a special prompt ('+'). When you hit Enter hat that
prompt, 'vim' gets a 'cont' signal and you can continue editing'.
Otherwise, if you hit Ctrl-Z again at the '+' prompt, you drop back into
the bash. There back to PicoLisp with 'fg', and Enter to 'vim'.
So this is the behavior I intended.
However, in Kriangkrai's situation, the spawned process (a shell) does
not receive any terminal input.
: (call 'sh "-c" "echo -n 'name: '; read name; echo $name")
This is not only a problem of raw mode - this can be handled with
setCooked() and setRaw() at proper places in doCall() - but of keyboard
input in general. That is, the 'read' in the shell immediately receives
EOF and returns.
I can get it to work if I take out all the "set process group" and "set
terminal foreground process group" handling from doCall(). But then
neither 'vim' nor the signal handling work any longer.
So, something must still be wrong. I just never noticed it because I
only called non-interactive processes (except 'vim').