upvote

points

by imankulov2 days ago |
comments
upvoteby verall2 days ago|
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!

reply
upvoteby gitaarik1 days ago|
parent|
[-]
Yeah or just use Ctrl + J
reply
upvoteby theshrike791 days ago|
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

reply
upvoteby strogonoff2 days ago|
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.

reply
upvoteby tolciho2 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.
reply
upvoteby a_t482 days ago|
parent|
next
[-]
That depends on how the children were spawned, no? prctl(PR_SET_PDEATHSIG, SIGTERM); or similar will fix this.
reply
upvoteby tolciho22 hours 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?
reply
upvoteby strogonoff2 days ago|
parent|
prev|
[-]
TIL. I didn’t know it’s the responsibility of the parent, thought OS automatically handles child processes.
reply
upvoteby tolciho22 hours 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.

reply
upvoteby flakes1 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.

reply
upvoteby strogonoff1 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…
reply
upvoteby patabyte2 days ago|
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.
reply
upvoteby lmao_ball2 days ago|
parent|
[-]
Interesting. I’ve just been using ‘\ + enter’
reply
upvoteby AlexCoventry1 days ago|
parent|
[-]
I just use Ctrl-g to open the prompt in emacs.
reply
upvoteby gitaarik1 days ago|
parent|
[-]
You can just use Ctrl + J
reply
upvoteby giwook1 days ago|
prev|
next
[-]
Or if you want to avoid having to set new bindings, do '\ + enter' (which escapes the enter).
reply
upvoteby ErroneousBosh1 days ago|
prev|
[-]
What does shift-enter do for you?
reply
upvoteby skydhash1 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.

reply