Absolutely Gorgeous !! add documentation about stdin/stdout redirections precautions for hard

[nonnenmacher]

Is your feature request related to a problem? Please describe.

This is more a documentation (or details) process.

When using launcher (e.g pumactl or some wrapper around rack builder, it often happen that
the stdin/stdout (and in a minor importance ? stderr) are closed or redirected elsewhere
(e.g std/null or a file for logging).

In those case, it seems that jard (pry) continue to work as one can see that pressing 'Ctrl-D'
close the standard input and then the whole process seems to continue and then accept the
'Ctrl-C' to terminate the parent process.

Describe the solution you'd like

It would be nice (I'll try to help) to detail what to do, in order to 'protect' the minimum
requirement needed by jard in order to keep the IO for its own use.

Additional context

I'm testing a Grape Application launched by puma (using pumactl) and possibly
the solution is here to see that the launcher do not touch any of 'terminal launched'
standard descriptors.

Possibly similar launch like 'xxxx.ru' rack launcher could be handler the same way.

This will allow tremendous benefits for debugging inside Docker container using manual 'launch'
of the Docker process/CMD as it is indicated here to not touch thoses. If handled properly
it could allow to 'debug' containers using terminal and docker -it .... commands.

Would be terrific !

[0x2c7]

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.

[0x2c7]

@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.

[nonnenmacher]

@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 ;-)

[0x2c7]

@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 😄