On Mon, Aug 09, 2021 at 01:19:08PM +0200, Ingo Schwarze wrote: > Hi, > > as mentioned earlier, deraadt@ reported that sftp(1) ignores Ctrl-C. > Fixing that without longjmp(3) requires making editline(3) better > behaved. > > Currently, when read(2) from the terminal gets interrupted by a > signal, editline(3) ignores the (first) signal and unconditionally > calls read(2) a second time. That seems wrong: if the user hits > Ctrl-C, it is sane to assume that they meant it, not that they > want it ignored. > > The following patch causes el_gets(3) and el_wgets(3) to return > failure when read(2)ing from the terminal is interrupted by a > signal other than SIGCONT or SIGWINCH. That allows the calling > program to decide what to do, usually either exit the program or > provide a fresh prompt to the user. > > If i know how to grep(1), the following programs in the base system > use -ledit: > > * bc(1) > It behaves well with the patch: Ctrl-C discards the current > input line and starts a new input line. > The reason why this already works even without the patch > is that bc(1) does very scary stuff inside the signal handler: > pass a file-global EditLine pointer on the heap to el_line(3) > and access fields inside the returned struct. Needless to > say that no signal handler should do such things... > > * cdio(1) > Behaviour is acceptable and unchanged with the patch: > Ctrl-C exits cdio(1). > > * ftp(1) > It behaves well with the patch: Ctrl-C discards the current > input line and provides a fresh prompt. > The reason why it already works without the patch is that ftp(1) > uses setjmp(3)/longjmp(3) to forcefully grab back control > from el_gets(3) without waiting for it to return. > > * lldb(1) > It misbehaves with or without the patch and ignores Ctrl-C. > I freely admit that i don't feel too enthusiastic about > debugging that beast. > > * sftp(1) > Behaviour is improved with the patch: Ctrl-C now exits sftp(1). > If desired, i can supply a very simple follow-up patch to sftp.c > to instead behave like ftp(1) and bc(1), i.e. discard the > current input line and provide a fresh prompt. > Neither doing undue work in the signal handler nor longjmp(3) > will be required for that (if this patch gets committed). > > * bgplgsh(8), fsdb(8) > I have no idea how to test those. Does anyone think that testing > either of them would be required?
I had a quick test with bgplgsh(8), hitting Ctrl-C exits bgplgsh. Same before with or without the diff. Not sure if anyone is actually using bgplgsh(8) -- I never used it. -- :wq Claudio
