Absolutely Gorgeous !! add documentation about stdin/stdout redirections precautions for hard about ruby_jard HOT 4 CLOSED

Interesting use case. I never use pumactl, but I totally understand that use cases, as well as more general cases when stdin/stdout/stderr are redirected. To be honest, I don't have any experience of how to deal with it correctly for now. There are some things pop from my head:

• It's true that Jard should detect when STDIN and STDOUT are redirected,or not TTY. In such cases, Jard should print a warning, and let the program continue and never attach the program.
• We can even go further than that, try to detect user/program tty, and work on those files instead. This approach is adopted by less, tmux, and other similar programs. They made use of dev/tty to do so. Luckily, it is supported by operation system level in both linux and mac, and independent to terminal emulator. I'm not really sure about the side effects though.
• About debugging containers, I would like to propose to use remote debugging instead. There are a lot of use cases that the debugging target is outside of developer machines, on staging VPS, or deep inside kubernetes clusters. docker -it or kubectl exec are not very friendly. Developers have to start the process inside, expose the ports, and work inside that foreign container. It's not as convenient as developer's local environment. All the output are streamed via the internet may cause lagging experience, and even weird quirks. Supporting remote debugging allows Jard interrupts a running server, debugs right in developer machine via a secure TCP socket with a proper protocol (DAP?). That solution serves more use cases, safer, and seems to be faster.

What do you think about this? Would love to hear more about it.

from ruby_jard.

@nonnenmacher it turns out that I already implemetned the solution that Jard detects user tty, and bind into that instead of STDIN/STDOUT. The solution is described at #51, and tested with "easy" redirection. However, I didn't solve the case that the process is detached, or created in an isolated process group, or doesn't have a tty device at all.

from ruby_jard.

@nonnenmacher it turns out that I already implemetned the solution that Jard detects user tty, and bind into that instead of STDIN/STDOUT. The solution is described at #51, and tested with "easy" redirection. However, I didn't solve the case that the process is detached, or created in an isolated process group, or doesn't have a tty device at all.

Its totally fine, for this it isn't a big problem to relaunch in non deamonized mode and possibly this is the way to go inside a Docker container anyway (not yet tested).

Great solution for either quick REPL/Debug on a dev server and in last resort before suicide on a production node
dirty investigation/hot fix ;-)

from ruby_jard.

@nonnenmacher I tested with docker. And it works, as soon as there is a tty device attached to the docker container. I noted it down at https://rubyjard.org/docs/guides/faq#can-ruby-jard-work-with-docker. I'll think of a safer solution to debug on production, but not sure who gonna have that use case though 😄

from ruby_jard.