beep is a console bell. I just got so tired of being limited to printf("a"); when I wanted a terminal beep. This program isn't supposed to be anything stupendous, it's just
supposed to get the job done. Its intended purpose in life is to live inside shell/perl scripts, and allow a little more granularity than you get with the default terminal bell. Maybe I'm the only one who thinks this is useful.
As noted in the man page, some users are running into a situation where beep dies with a complaint from ioctl(). The reason for this, as Peter Tirsek was nice enough to point out to me, stems from how the kernel handles beep's attempt to poke at (for non-programmers: ioctl is a sort of catch-all function that lets you poke at things that have no other predefined poking-at mechanism) the tty, which is how it beeps. The short story is that the kernel checks that either:
- you are the superuser
- you own the current tty
What this means is that root can always make beep work (to the best of my knowledge!), and that any local user can make beep work, BUT a non-root remote user cannot use beep in it's natural state. What's worse, an xterm, or other x-session counts, as far as the kernel is concerned, as 'remote', so beep won't work from a non-priviledged xterm either. I had originally chalked this up to a bug, but there's actually nothing I can do about it, and it really is a Good Thing that the kernel does things this way. There is also a solution.
By default beep is not installed with the suid bit set, because that would just be zany. On the other hand, if you do make it suid root, all your problems with beep bailing on ioctl calls will magically vanish, which is pleasant, and the only reason not t is that any suid program is a potential security hole. Conveniently, beep is very short, so auditing it is pretty straightforward.
What's New in This Release:
Comments not found