I left tmux for zellij after several unsuccessful attempts to get Shift+Enter working.

Was quite impressed initially and invested weeks in building new muscle memory, but somehow Zellij crashed with panic more than once, leaving all my processes orphaned. Decided to go back to tmux, and found a simple fix for my Shift+Enter issue.

In case anyone is looking for it, the fix is "bind-key -T root S-Enter send-keys C-j" borrowed from https://github.com/anthropics/claude-code/issues/6072.

▲ verall 2 days ago | parent | next [-]

> In case anyone is looking for it, the fix is "bind-key -T root S-Enter send-keys C-j"

I was looking, thank you!

	▲	gitaarik a day ago \| parent [-]
		Yeah or just use Ctrl + J

▲ strogonoff 2 days ago | parent | prev | next [-]

Is it possible for a multiplexer process to die, but in such a bad way that its child processes continue to run?

I’ve been relying on the fact that in the worst-case scenario (if a pane hangs and tmux session becomes unresponsive) I can just kill tmux server and not have to hunt down and kill dozens of individual processes afterwards.

▲ tolciho 2 days ago | parent [-]

A `kill -9` will cause many a process to die and give no chance to cleanup any child processes. Some percentage of users continue to use `kill -9` by default, which may result in a mess of a process tree. Otherwise if the crash is bad enough that cleanup code cannot run (maybe it's being run on OpenBSD and an incompetent programmer didn't check the return value of a malloc and for some reason the kernel now nukes the process) then there may be orphan children. There may also be sporadic failures to cleanup if the crash, maybe, causes the whole process to exit before the cleanup code in some other thread can run. System load average may also influence how things maybe go sideways.

▲ a_t48 2 days ago | parent | next [-]

That depends on how the children were spawned, no? prctl(PR_SET_PDEATHSIG, SIGTERM); or similar will fix this.

	▲	tolciho a day ago \| parent [-]
		`$ man prctl man: No entry for prctl in the manual.` Maybe more linux will slop into POSIX and thence into OpenBSD in the fullness of time?

▲ strogonoff 2 days ago | parent | prev [-]

TIL. I didn’t know it’s the responsibility of the parent, thought OS automatically handles child processes.

▲

tolciho a day ago | parent | next [-]

Typically upon control+c being mashed in a shell (unless the terminal is in raw mode or such) a SIGINT signal is sent to all members of the foreground process group, and most of the processes in that group (ideally, probably) go away. This usually includes a portion of the shell (which forked itself to spawn the pipeline or whatever, to call setpgid(2), etc) that usually ignores the signal. In this case it may seem like the OS is doing something, but really it's shell job control (assuming your shell has job control, which most now do, and that you haven't turned "monitor" off, which most folks do not). The kernel is mostly there for shuttling signals around and process bookkeeping.

However a different process management model is that each parent must in turn signal its child processes to exit, in which case if the parent dies before that can happen you easily get orphan processes. There are use cases for both the process group model and individual signal models, and pros and cons to each.

▲

flakes 2 days ago | parent | prev [-]

When a child process finishes (that is not actively being waited on) it is left in a "defunct" or "zombie" state and will stick around in the process table until the parent process waits on them to fetch exit code. When you kill a parent process with active children, these subprocesses will become orphaned and re-parented to the OS pid 1 (or another "sub-reaper" process depending on your setup).

The OS will typically not kill orphaned/re-parented processes for you. It will simply wait/reap them so they are not left as zombies once they complete. If your parent process spawns something like a daemon server that needs an explicit signal to be stopped (e.g. SIGINT/SIGTERM), these processes will continue to run in the background until they are manually killed or they crash.

	▲	strogonoff 2 days ago \| parent [-]
		I see, so I might still need to hunt down non-daemon but hung processes even after I kill tmux server in which I ran them. Might explain a couple of odd occurrences in the past…

▲ theshrike79 a day ago | parent | prev | next [-]

I ended up with this: bind -n S-Enter send-keys Escape '[13;2u'

pi.dev keeps complaining that "set -s extended-keys on" is missing, but it still works :D

▲ patabyte 2 days ago | parent | prev | next [-]

Interesting, for me `shift+enter` hasnt worked, but `option+enter` does give me new lines in Claude Code's promptbox inside tmux on MacOS.

▲

lmao_ball 2 days ago | parent [-]

Interesting. I’ve just been using ‘\ + enter’

▲

AlexCoventry 2 days ago | parent [-]

I just use Ctrl-g to open the prompt in emacs.

	▲	gitaarik a day ago \| parent [-]
		You can just use Ctrl + J

▲ giwook 2 days ago | parent | prev | next [-]

Or if you want to avoid having to set new bindings, do '\ + enter' (which escapes the enter).

▲ ErroneousBosh 2 days ago | parent | prev [-]

What does shift-enter do for you?

	▲	skydhash 2 days ago \| parent [-]
		Maybe some keybind in a software. Another mentions Claude code, so it may be used to enter new line where enter is bound to send the prompt. Terminal programs don’t see key events. It’s all text. I just checked st (suckless) code and the RETURN key will send “\r” aka carriage return. Control+j is “\n” or line feed.