Package: beep Version: 1.2.2-22 Severity: minor Tags: patch
Found a few typos in '/usr/share/man/man1/beep.1.gz', see attached '.diff'. Hope this helps... -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C) Shell: /bin/sh linked to /bin/dash Versions of packages beep depends on: ii debconf [debconf-2.0] 1.5.23 Debian configuration management sy ii libc6 2.7-13 GNU C Library: Shared libraries beep recommends no packages. beep suggests no packages. -- debconf information excluded
--- beep.1 2008-08-16 11:43:47.000000000 -0400 +++ /tmp/beep.1 2008-09-04 02:35:14.000000000 -0400 @@ -46,7 +46,7 @@ \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 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. @@ -92,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
