[CBLT]

If you're following a pipe (such as `kubectl logs | less +F`), <C-c> is sent to all processes in a pipeline, so it stops less from following and it stops the other process entirely. Then you can't start following again with F, or load more data in with G.

Less provides an alternative of <C-x> to stop following, but that is intercepted by most shells.

[vbezhenar]

> Less provides an alternative of <C-x> to stop following, but that is intercepted by most shells.

WoW, thanks a lot! That was my pain for many years. C-x works in Gnome Console just fine.

[mananaysiempre]

Funnily enough, it literally tells you right there on the bottom line: “Waiting for data... (^X or interrupt to abort)”. No shame in not noticing, just another case of blindness to long-familliar messages I guess.

[mananaysiempre]

By the shell or by the kernel’s terminal discipline or by the terminal emulator? AFAIU the shell is basically out of the picture while `less` is running.

[CBLT]

I can <C-z> while less is running to background that process using the shell, so the shell is clearly not completely gone.

I might be misremembering, but I think I just had to rebind <C-x> in zsh to get less working.

[mananaysiempre]

> I can <C-z> while less is running to background that process using the shell, so the shell is clearly not completely gone.

The shell isn’t gone, but it isn’t active either from what I understand. The function of converting the user’s typing ^Z on a terminal (or a ^Z arriving on the master end of a pseudoterminal) into a SIGTSTP signal to the terminal’s foreground process group is[1] a built-in function of the kernel, much like for ^C and SIGINT or ^\ and SIGQUIT. (The use of ^Z resp. ^C or ^\ specifically, as well as the function being active at all, is configurable via a TTY ioctl wrapped by termios wrapped in turn by `stty susp` resp. `stty intr` or `stty quit`.) So is the default signal action of stopping (i.e. suspending) the process in response to that signal. The shell just sees its waitpid() syscall return and handles the possibility of that having happened due to the process stopping rather than dying (by updating its job bookkeeping, making itself the foreground process group again, and reëntering the REPL).

I am not saying that doing job control by filtering the child’s input would be a bad design in the abstract, and it is how terminal multiplexers work for instance. I admit the idea of kernel-side support for shell job control is pretty silly, it’s just how it’s traditionally done in a Unix system.

[1] https://www.gnu.org/software/libc/manual/html_node/Concepts-...

[fuzztester]

Whew! Advanced Unix system programming level stuff. I've dabbled a bit in that field, in C, on Unix, some older versions on PCs. It was fun. Any recommendation for a tutorial style book or site or blog on the subject, other than man pages and the Kerrisk book (TLPI, which is more of a reference), for Linux?

[obezyian]

I think by "out of the picture" PP meant that the shell is not processing the input, not that it has exited.

C-z is not processed by the shell but by the terminal "infrastructure".

You can disable it, or change the key binding, and a lot more, with stty(1).