-
-
Notifications
You must be signed in to change notification settings - Fork 28
Absolutely Gorgeous !! add documentation about stdin/stdout redirections precautions for hard #38
Comments
Interesting use case. I never use
What do you think about this? Would love to hear more about it. |
@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 Great solution for either quick REPL/Debug on a dev server and in last resort before suicide on a production node |
@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 😄 |
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 aroundrack builder
, it often happen thatthe
stdin/stdout
(and in a minor importance ?stderr
) are closed or redirected elsewhere(e.g
std/null
or afile
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
(usingpumactl
) and possiblythe 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 properlyit could allow to 'debug' containers using terminal and
docker -it ....
commands.Would be terrific !
The text was updated successfully, but these errors were encountered: