On Sat, Oct 19, 2024 at 4:03 AM Greg Wooledge <g...@wooledge.org> wrote: > > The more-portable version of this is printf '\a'. > > The issue, though, is that what the terminal *does* with this \007 > byte depends on a truly formidable number of different settings and > layers. The terminal may cause the system to beep, or it may flash, > or it may do nothing at all.
Most gui terminals probably have a configuration setting somewhere to determine whether the terminal bell is on / off or whether it should be a visible flash. > > Arbol One could try printf '\a' and see what happens. If they get a > beep, then all is well, and they can use this however they see fit. > But if it doesn't beep, then trying to diagnose *why* could be tricky. > > If diagnosis/modification is needed, they might start with "xset q" > and see whether the bell is enabled in that particular layer. If > not, xset can change that setting. If the bell is enabled in xset but > still not audible, then I don't know what the next layer to check is. > (GNOME? ALSA? Pulse audio? Pipewire?) AFAIK, the classical terminal bell does not use the audio stack like alsa / pulse. It handles the tiny buzzer/beeper on the motherboard. But some newer gui terminals might be making things more complex. Another issue is that some newer motherboards might not even have the beeper physically installed. Assuming default /etc/inputrc, logging in at the text console (Ctrl+Alt+F[1-6]) and hitting backspace or tab on an empty prompt should result in an audible beep if the beeper is present and working.
