fix(tauri-utils): include \n in io::read_line, closes #6388

[amrbashir]

What kind of change does this PR introduce?

• Bugfix
• Feature
• Docs
• New Binding issue #___
• Code style update
• Refactor
• Build-related changes
• Other, please describe:

Does this PR introduce a breaking change?

• Yes, and the changes were approved in issue #___
• No

Checklist

• When resolving issues, they are referenced in the PR's title (e.g fix: remove a typo, closes #___, #___)
• A change file is added if any packages will require a version bump due to this PR per the instructions in the readme.
• I have added a convincing reason for adding this feature, if necessary

Other information

[lucasfernog]

I see the value of keeping this compatible with the Rust std library, but I worry this is a breaking change for some users. Maybe we could target this for v2 instead.

The use case of the issue is also a little weird ( but I need to know if that newline character was present or not in the stdout.). If there's no newline or \r in the output, Tauri will keep waiting for it to appear and never give the bytes to the user, so he will end up not knowing this anyway.

Currently if the line does not end with \r, then you're sure it ends with \n and can append it on your end.

[amrbashir]

I see the value of keeping this compatible with the Rust std library, but I worry this is a breaking change for some users. Maybe we could target this for v2 instead.

tbh I see it as a bug fix so not a breaking change

The use case of the issue is also a little weird ( but I need to know if that newline character was present or not in the stdout.). If there's no newline or \r in the output, Tauri will keep waiting for it to appear and never give the bytes to the user, so he will end up not knowing this anyway.

Currently if the line does not end with \r, then you're sure it ends with \n and can append it on your end.

While that maybe true, it is a bad DX (showcased in the example you added) and beside the use case of the issue, unix and windows had different behaviors which needs to align and if you align any of them to the other it will break for some users so I'd rather just fix the buggy behavior and align with rust.