-
Notifications
You must be signed in to change notification settings - Fork 5.2k
Implement Console.Beep via bell character instead of Windows API
#102685
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
Conversation
implement Console.Beep via BEL char, rather than the original pinvoke.
stdout/err when redirected
|
Added When you commit this breaking change:
Tagging @dotnet/compat for awareness of the breaking change. |
|
@jkotas Could you kindly send the DL for me? |
The breaking change notification should be done by @dotnet/area-system-console owners once the PR is merged. |
Ah, sorry. Per the bot message I thought this needs to be done by me. |
adamsitnik
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@karakasa thank you for providing high quality contribution (I really liked the tests)!
@jkotas it's more like a bug fix to me. Do you really believe we should provide breaking change docs for this PR? |
|
|
||
| if (!Console.IsOutputRedirected) | ||
| { | ||
| Console.Out.Write(BellCharacter); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Won't this break beeps if someone has used Console.SetOut to hook console writing?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Console.SetOut will make Console.IsOutputRedirected return true.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Console.SetOutwill makeConsole.IsOutputRedirectedreturntrue.
That is not the case.
using System.Text;
var ms = new MemoryStream();
var orig = Console.Out;
Console.SetOut(new StreamWriter(ms) { AutoFlush = true });
Console.WriteLine(Console.IsOutputRedirected);
Console.SetOut(orig);
Console.WriteLine(Encoding.UTF8.GetString(ms.ToArray()));That prints false.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I just tried this:
Console.SetOut(new StringWriter());
Console.Beep();It used to beep. With this PR, it no longer does.
Console.Beep is going to produce whatever jingle is configured for the bell character in your Windows or terminal settings. It is going to be very different sound from the Beep that it produces today. I think it qualifies as a breaking change. Run the following to see the difference: Console.Beep();
Thread.Sleep(1000);
const char BellCharacter = '\u0007';
Console.Out.Write(BellCharacter);Also, the docs need to be updated. https://learn.microsoft.com/en-us/dotnet/api/system.console.beep says that "the beep plays at a frequency of 800 hertz for a duration of 200 milliseconds." and "Beep wraps a call to the Windows Beep function" that is not going to be the case after this change. |
| return; | ||
| } | ||
|
|
||
| if (!Console.IsErrorRedirected) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The Unix version of this function does not write to stderr. Should we try to be consistent between Windows and Unix - produce the bell character for !Console.IsOutputRedirected only?
|
|
||
| if (!Console.IsOutputRedirected) | ||
| { | ||
| Console.Out.Write(BellCharacter); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we really want to do what this PR is doing, we shouldn't be going to Console.Out. We should instead do what the unix implementation does, which is going directly to the stdout handle / file descriptor, such that it won't target Console.Out and any custom writer it may have been redirected to, e.g.
| => WriteTerminalAnsiString(value, Interop.Sys.FileDescriptors.STDOUT_FILENO, mayChangeCursorPosition: false); |
In the meantime, though, I suggest this PR be reverted.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the meantime, though, I suggest this PR be reverted.
I am going to give it a try and if I can not implement it in 1h I am going to revert the PR. Does that sound OK @stephentoub ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup, thanks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That said, I'm still not sure about the premise of this change. Isn't it strange that Beep with and without parameters are now fundamentally different? This goes to Jan's points about this being a breaking change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That said, I'm still not sure about the premise of this change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That said, I'm still not sure about the premise of this change.
I know what's written in the issue. What I meant was I'm not sure it's a desirable change, given the other Beep overload and back compat. It is a breaking change to be documented, at a minimum.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've sent #104966
Fix #102211
The behavioral breaking change would require a later document change.