---- beep.1.orig 2008-07-28 19:20:08.000000000 +0200
-+++ beep.1 2008-07-28 19:25:05.000000000 +0200
+--- beep.1.orig 2009-03-24 19:02:59.000000000 +0100
++++ beep.1 2009-03-24 19:04:30.000000000 +0100
@@ -1,12 +1,12 @@
-.TH BEEP 1 "March 2002"
+.TH BEEP 1 "July 2008"
+\fBbeep\fR \-f 1000 \-n \-f 2000 \-n \-f 1500
-would produce a sequence of three beeps, the first with a frequency of 1000Hz (and otherwise default values), then a second beep with a frequency of 2000Hz (again, with things like delay and reps being set to their defaults), then a third beep, at 1500Hz. This is different from specifying a -r value, since -r repeats the same beep multiple times, whereas -n allows you to specify different beeps. After a -n, the new beep is created with all the default values, and any of these can be specified without altering values for preceeding (or later) beeps. See the \fBEXAMPLES\fR section if this managed to confuse you.
-+would produce a sequence of three beeps, the first with a frequency of 1000Hz (and otherwise default values), then a second beep with a frequency of 2000Hz (again, with things like delay and reps being set to their defaults), then a third beep, at 1500Hz. This is different from specifying a \-r value, since \-r repeats the same beep multiple times, whereas \-n allows you to specify different beeps. After a \-n, the new beep is created with all the default values, and any of these can be specified without altering values for preceeding (or later) beeps. See the \fBEXAMPLES\fR section if this managed to confuse you.
++would produce a sequence of three beeps, the first with a frequency of 1000Hz (and otherwise default values), then a second beep with a frequency of 2000Hz (again, with things like delay and reps being set to their defaults), then a third beep, at 1500Hz. This is different from specifying a \-r value, since \-r repeats the same beep multiple times, whereas \-n allows you to specify different beeps. After a \-n, the new beep is created with all the default values, and any of these can be specified without altering values for preceding (or later) beeps. See the \fBEXAMPLES\fR section if this managed to confuse you.
.TP
\fB\-s\fR, \fB\-c\fR
-these options put \fBbeep\fR into input-processing mode. -s tells \fBbeep\fR to read from stdin, and beep after each newline, and -c tells it to do so after every character. In both cases, the program will also echo the input back out to stdout, which makes it easy to slip \fBbeep\fR into a text-processing pipeline, see the \fBEXAMPLES\fR section.
will produce first two 1000Hz beeps, then 5 beeps at the default tone, but only 10ms long each, followed by a third beep using all the default settings (since none are specified).
.PP See also the \fBFREQUENCY TABLE\fR below.
+@@ -81,7 +92,7 @@
+ .PP
+ - you own the current tty
+ .PP
+-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.
++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-privileged 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.
+ .PP
+ 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 to is that any suid program is a potential security hole. Conveniently, beep is very short, so auditing it is pretty straightforward.
+ .PP
projects / pkg / beep.git / blobdiff