-
-
Notifications
You must be signed in to change notification settings - Fork 241
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
pty.start() #50
Comments
Can you provide a sample snippet to reproduce? |
I only get that when trying to compile on Windows. The run.go file (which is the only reference of This should shouldn't be a huge surprise to anyone given the nature of this library. For my own project I just fell back to Golang's core libraries if the target OS is Windows. As you know, it would be pretty easy to do the same in this package to save users working around that; but again given the nature of this package, it could be argued a pointless exercise (which is why I didn't raise a pull request). |
Feel free to open a PR and we can discuss about it there :) |
@imorg how can you fall bell back to golang core libraries? can you give me a example? |
I just did the switching inside my own package by having the PTY package called from its own The relevant code is inside Hope this helps |
It's worth noting that https://github.com/containerd/console has a console implementation for Windows. There's quite a bit of overlap with this library. |
The same prompt suddenly appeared yesterday。 |
Closing in favor of the more generic #95 |
- On Windows, we use the standard os/exec functionality. As Windows doesn't really have the concept of a PTY. - On Unix, we use a PTY. This allows commands started through effect to appear like a user is actually running them. In many cases, this doesn't matter, but some commands will change their output if there is a user or pipe. The PTY fakes the spawned process into thinking it's a user. This will generally cause the spawned process to emite human-friendly output. - This change is due to the fact that recent Windows builds of paketo-buildpacks/procfile have been failing. This traces back to creack/pty#50. It's not clear why this is happening now, since the issue is a few years old. With recent changes in libpak, we're now affected by this. - Initial tests with paketo-buildpacks/procfile show that making the PTY stuff conditional on the OS, allows this to work as expected. Signed-off-by: Daniel Mikusa <[email protected]>
why i cat use pty.start()?it point out that "undefined: pty.Start"
The text was updated successfully, but these errors were encountered: