Refer to the manual page bits for details.
Details
- Reviewers
oskar.holmlund_ohdata.se - Group Reviewers
Accessibility
beep -t "Hi"
beep -t "ERROR" -D 50
beep -F 110 -t "Hi, this is a test." -D 50
beep -n 0
beep -n 1
beep -n 2
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Skipped - Unit
Tests Skipped
Event Timeline
Technically you could render two different strings at the same time, if using different frequencies!
Manual page itself LGTM, but I would make it use Unicode (or whichever encoding) units, not bytes. With bytes, LSB-first breaks down in the presence of UTF-8, for instance (and all the 1 bits in the first byte would only make it worse). Consider, for instance, beep -t "Ψωμί! Παιδειά! Και όχι επαιτειά!"
Would it work if the intermediate format was UTF-8, but all characters would be output as 16-bit unicode?
Beware that Unicode itself can go beyond 16-bit. I think the kernel supports 21-bit unicode, so should we print everything like 21 bits?
Any opinions?
I'm not sure, but leaning toward "no" because there are enough scripts in common use in the SMP (Hanifi Rohingya comes to mind), SIP (CJK), and TIP (CJK) to require 2 UTF16 codepoints very often.
Beware that Unicode itself can go beyond 16-bit. I think the kernel supports 21-bit unicode, so should we print everything like 21 bits?
21 bits? Oh right, plane 16. Hmm. Maybe stop (or start, depending on output order) at the most significant nonzero byte of the UCS4 codepoint? That's probably lossy, but I'm not sure it matters except for airgap-bridging use cases.
No bare metal to run 14 on, but if it would work in a VirtualBox VM, I can try in a few days.
usr.bin/beep/beep.1 | ||
---|---|---|
67 |
I think no one has worked on this still, so feel free to take this. You can add me as a reviewer if you want.