Skip to content
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

[SR-13806] Incorrect I/O on Windows when using swift run #4480

Closed
swift-ci opened this issue Nov 2, 2020 · 6 comments
Closed

[SR-13806] Incorrect I/O on Windows when using swift run #4480

swift-ci opened this issue Nov 2, 2020 · 6 comments
Assignees

Comments

@swift-ci
Copy link
Contributor

swift-ci commented Nov 2, 2020

Previous ID SR-13806
Radar None
Original Reporter svanimpe (JIRA User)
Type Bug
Status Resolved
Resolution Done
Environment

29/10 snapshot on Windows

Additional Detail from JIRA
Votes 0
Component/s Package Manager
Labels Bug, Windows
Assignee @compnerd
Priority Medium

md5: 2ad6ec2ac664ac4812b9f111d7f68e2f

Issue Description:

When I run a Swift package with swift run, the I/O behaves weird. There can be shell prompts mixed in with the output, the input is sometimes parsed by the shell and not sent to the application, and the cursor can jump to different positions on the screen.

Here is a sample main.swift you can try:

func readBool(question: String) -> Bool {
    var answer: String
    repeat {
        print("\(question) (y/n): ", terminator: "")
        answer = readLine()!
    } while answer != "y" && answer != "n"
    return answer == "y"
}

while readBool(question: "Do you feel lucky? �") { }

Note that the application behaves correctly when I run the executable directly. It is only when I use swift run that I see these issues.

@compnerd
Copy link
Collaborator

compnerd commented Nov 2, 2020

+@abertelrud @neonichu @tomerd

Anders or Boris may have an idea of the top of their heads where this might be going awry.

@abertelrud
Copy link
Contributor

Looks like it calls `execve`, but it does something to combine stdout and stderr first. We'd need to step through the code here (it's new to me).

@swift-ci
Copy link
Contributor Author

Comment by Steven Van Impe (JIRA)

@egorzhdan The Swift plugin for CLion seems to have the same problem. I see this issue when running a package with the Play button, but not when running the executable directly from the command line

https://youtrack.jetbrains.com/issue/CPP-26699

@compnerd
Copy link
Collaborator

I think that I might have an idea of what is going on here. The ultimate issue is that use of TSCBasic.exec is not a good idea. The problem is that there is no real way to implement exec on Windows - the concept does not map at all to Windows' process handling and I don't think that it can be emulated. While there might be a way to do a partial approximation of this on Windows, it will not be entirely correct. For example, PID inheritance will not be possible and this is user visible (e.g. getpid before and after the exec would be different). We might be able to create a break-away, kill-on-close job and wait for the job to terminate before returning, but it is effectively going to be a spawn & waitpid. The process launch is the reason that the console actually appears to be in an indeterminate state - the process was launched in the background, the console control was returned and the process inherited the console for I/O resulting in the executed process printing and reading from the console at the same time as the actual command interpreter.

@compnerd
Copy link
Collaborator

apple/swift-tools-support-core#283 should address the issue, even though it does not match the exec semantics identically.

@compnerd
Copy link
Collaborator

That is now merged, will need to wait for a new snapshot to pick it up.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
@shahmishal shahmishal transferred this issue from apple/swift May 4, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants