spkr-beep / beep Goto Github PK

On https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=922763
they say to tell you directly about those documentation improvements.

Have you considered adding a code of conduct to make the project more friendly to newcomers?

The always brilliant Bjarni Ingi Gislason has a number of well written ideas and suggestions and a patch for the beep.1 man page at Debian Bug 1071391.

For details, refer to the Debian bug. This issue is just to keep all issues in one place and give an easy to find and click place to find the details.

Thank you for picking this package up, I was concerned that my beloved beep had to go after discovering the suid security issues.
I apologize for this somewhat nitpicking bug report and won't be offended if you just close it. I made a Gentoo ebuild that I may submit and all works fine with a small amount of finesse. However in the install phase it reports "FATAL: Not a git repository" (It affects nothing, but it's ugly). This is simply git giving up on the helper commands at the end of GNUmakefile, but since I am using the tar.gz package at "https://github.com/spkr-beep/beep/archive/v1.4.7.tar.gz" I don't believe these commands are relevant, shouldn't be in the package version
. I remove them with a patch and all goes well, but I believe the bug belongs here. Thanks for your time, it's working great here.

--- a/GNUmakefile	2020-02-05 19:44:22.948088696 -0800
+++ b/GNUmakefile	2020-02-05 19:47:09.293940985 -0800
@@ -34,7 +34,6 @@
 DOT = $(call pathsearch,dot)
 DOXYGEN = $(call pathsearch,doxygen)
 EGREP = $(GREP) -E
-GIT = $(call pathsearch,git)
 GREP = $(call pathsearch,grep)
 INSTALL = $(call pathsearch,install)
 MKDIR_P = mkdir -p
@@ -422,28 +421,6 @@
 	for f in $(man1_DATA);     do rm -f "$(DESTDIR)$(man1dir)/$$f";   done
 	for f in $(pkgdoc_DATA);   do rm -f "$(DESTDIR)$(pkgdocdir)/$$f"; done
 
-
-########################################################################
-# Development helpers
-########################################################################
-
-# List all references to documentation in the git repo
-.PHONY: refs
-refs:
-	$(GIT) grep -n -E '((http|https)://[a-zA-Z0-9\._/-]+|([A-Z]+\.md)|([a-zA-Z][a-zA-Z0-9_-]+\([0-9]+\)))'
-
-# List all TODOs and FIXMEs in the git repo
-.PHONY: todo fixme
-todo fixme:
-	$(GIT) grep -n -E '(TODO:|FIXME:|\\todo\s|@todo\s)'
-
-# Generate a kind of dist tarball to help with preparing for release
-PACKAGE_TARBASE := $(PACKAGE_TARNAME)-$(shell $(GIT) describe --tags | $(SED) 's/^v\([0-9]\)/\1/')
-.PHONY: dist
-dist:
-	$(GIT) archive --format=tar.gz --verbose --prefix=$(PACKAGE_TARBASE)/ --output=$(PACKAGE_TARBASE).tar.gz HEAD
-
-
 ########################################################################
 # End of GNUmakefile
 ########################################################################

beep wouldn't work at all for me until I ran
sudo modprobe pcspkr

I didn't see any mention of this in the documentation.

Xubuntu 20.04

I'm wondering if the way 'beep' checks for 'sudo' can be improved. Checking for "SUDO_..." environment variables seems too simple. For example the following makes 'beep' run without complaining:

sudo env --unset=SUDO_{GID,COMMAND,USER,UID} beep

or:

sudo env -i beep

Maybe one way to do it instead would be to go through parent processes to find if 'sudo' is involved anywhere in the process tree? Hopefully the 'sudo' process name wouldn't be easily changed unlike the environment?

Here's some more alternatives besides 'env' to change the environment and run 'beep':

sudo bash -c 'unset SUDO_{UID,GID,COMMAND,USER}; beep'
sudo perl -e 'map { delete $ENV{$_} } grep /^SUDO_/, keys %ENV; exec "beep"'
sudo perl -e 'undef %ENV; exec "beep"'
sudo awk 'BEGIN{ for (x in ENVIRON) { if (x ~ /^SUDO_/) { delete ENVIRON[x] } } system("beep") }'

I installed beep

sudo apt-get install beep

and run it like that

beep

not sound, no errors.

this is the output of beep --debug

[user@deb beep] $ beep --debug
beep: Verbose: beep_drivers_register 0x5583d70fa600 (console)
beep: Verbose: beep_drivers_register 0x5583d70fa660 (evdev)
beep: Verbose: evdev driver_detect 0x5583d70fa660 (nil)
beep: Verbose: b-lib: opened /dev/input/by-path/platform-pcspkr-event-spkr as 3
beep: Verbose: beep: using driver 0x5583d70fa660 (name=evdev, fd=3, dev=/dev/input/by-path/platform-pcspkr-event-spkr)
beep: Verbose: 1 times 200 ms beeps (100 ms delay between, 0 ms delay after) @ 440 Hz
beep: Verbose: evdev driver_begin_tone 0x5583d70fa660 440
beep: Verbose: evdev driver_end_tone 0x5583d70fa660
beep: Verbose: evdev driver_end_tone 0x5583d70fa660
beep: Verbose: evdev driver_fini 0x5583d70fa660

that's what happening when i modprobe pcspkr

sudo modprobe -r pcspkr
sudo modprobe pcspkr

dmesg
[  759.562893] input: PC Speaker as /devices/platform/pcspkr/input/input29

Let me know if this is a NetBSD issue and not valid to post here.

When trying to compile, per the INSTALL.md

make
make install

make can not 'see' the make file. When using the -f option and using GNUMakefile, a plethora of errors spit out (mostly regarding Needing an operator).

Here is what I get when running file on make. I could not seem to get it to say it's version. Perhaps it does not.
ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /usr/libexec/ld.elf_so, for NetBSD 9.2, not stripped

GCC version:
gcc (nb4 20200810) 7.5.0

Anyone know what I can do here?

-C (l|e) <first freq> <last freq>

Thank you for overseeing this project.

Cursed to use Arch Linux on one, last machine for the foreseeable future, one of the beep packages I use recently pointed its upstream URL your way (1.3-4 -> 1.4.4-1).

I set up permissions using the beep group method described in PERMISSIONS.md and immediately noticed sluggish, staggered response. Consider the following eight-note scale:

■ Test () { beep -l 250 -f 262 ; beep -l 250 -f 294 ; beep -l 250 -f 330 ; beep -l 250 -f 349 ; beep -l 250 -f 392 ; beep -l 250 -f 440 ; beep -l 250 -f 494 ; beep -l 250 -f 523 ; } ; time Test

real    0m2.466s
user    0m0.012s
sys     0m0.008s

In other words, your fork takes 23% longer to execute than it should--and it staggers from note to note. Do you know why? Do you know of any workarounds?

Thank you for reading.

■ uname -srvmo
Linux 5.0.7-arch1-1-ARCH #1 SMP PREEMPT Mon Apr 8 10:37:08 UTC 2019 x86_64 GNU/Linux

The Linux struct input_event structure actually contains not only the .type, .code and .value members for EV_SND, SND_TONE and the frequency, but also a struct timespec.

We should verify that the struct timespec is ignored by the kernel. Otherwise, it might be possible to move the delays from userspace into the kernel, similar to the BSD API.

Hi,

just wanted to drop a note, that I enjoy this since a day or so. Thank you very much.

I've packaged it for openSUSE here and attempt to submit this to the official channels.

I've found one nitpick: the default length isn't documented in the man page, as well as not any default is noted in --help. Both would be nice.

Anyway, great work.

This appears interesting for the evdev driver: johnath#17

Traditionally, beep has been using a combination of the -f, -l, -D, -d, and -n parameters to specify notes and sequences of notes.

I am certain there are better ways to write notes in a way which is both less verbose, and easier to read and write at the same time. I am also certain that over the last 20 to 40 years, there must have been utilities using notations which at least give good ideas.

This issue is to discuss and document better ways to write notes, and to discuss integrating a better note notation into beep.

I would think that SIGTSTP shown as ^Z should pause a long tone from playing and start playing again when fg is entered. And if not that then just halt the process the same as SIGINT - ^C.

Or is there a reason that it's this way that I am missing?

I ask because I just pressed Ctrl + Z by accident and couldn't stop the speaker. I had to run sudo rmmod pcspkr so I wouldn't have to listen to it while I looked up how to reverse a SIGSTP for if I did that again.

#25 pointed out that the documentation never says which driver to load. This affects more than one documentation file, so this issue tracks what the partial documentation rewrite needs to address.

• The Linux kernel contains more than one driver implementing the EV_SND/SND_TONE evdev API. Userspace implementations are also possible.
• Every kernel driver produces a hardware specific well known device aliases (mention some of them.
• udev will create devices and well known device aliases
• how to re-run udev to create device aliases like a system reboot does
• how to use lsmod and modprobe to ensure a driver is loaded in case udev does not work
• README.md should mention the Linux drivers
• PERMISSIONS.md needs adaptations (well known names)

Not sure how to explain this apart from as an example. I'd like to do something like

#!/usr/bin/beep
-f 1006.25 -l 160.0 -d 0 -D 0 
-f 1025.0 -l 160.0 -d 0 -D 0 
-f 1000.0 -l 160.0 -d 0 -D 0 
-f 1037.5 -l 160.0 -d 0 -D 0 
-f 1031.25 -l 160.0 -d 0 -D 0 -n -f 1031.25 -l 160.0 -d 0 -D 0 
-f 1012.5 -l 160.0 -d 0 -D 0 
-f 1018.75 -l 160.0 -d 0 -D 0 
-f 1012.5 -l 160.0 -d 0 -D 0 

Basically, have beep read the file or from stdin with the beep commands, and play the tones accordingly on each new line or -n

Perhaps beep should ship a proper appstream metadata.xml file (cf https://freedesktop.org/software/appstream/docs/chap-Quickstart.html etc.)

This is a feature request:

There should be an easy to use, easy to type way to add a beep specific thing to a shell command line which beeps sounding successfully if the last shell command's exit code was 0, and sounding failure-like when the last shell command's exit code was non-0.

beep/beep-main.c contains the magic number 300000U four times from lines 268 to 296 restricting, among others, the time for the delay -d and -D switches to 300 s or 5 min.

I used to use beep for simple remind-me-in-x-min tasks (like getting the pizza from the oven 🍕), but now that is not possible anymore (without some wrapper script etc. pp.). Also, calling usage_bail() was unhelpful to me in that case, because the documentation does not state this limit and the program still refuses to work with a perfectly acceptable (according to documentation) invocation.

Maybe I am missing something, but what was the reasoning behind this seemingly arbitrary limit? 🤔

(Also, thank you very much for picking up an unmaintained project 🥺👍)

In my /etc/rc.local, I start a tmux session via the following command :

sudo -u daniel -- tmux new-session -d -s irc /usr/bin/irssi

The tmux daemon is thus started and permanently running while managing the irc session, which runs /usr/bin/irssi. However, this also means that that session - and every new session I create, since tmux apparently fills the sessions' environment with the same variables that the tmux daemon had while it started - contains the following variables :

$ printenv | grep SUDO
SUDO_GID=0
SUDO_COMMAND=/usr/bin/tmux new-session -d -s irc /usr/bin/irssi
SUDO_USER=root
SUDO_UID=0

This immediately means that running beep in any of these tmux sessions is impossible due to it checking the existence of every one of these variables.

Since sudo is used with -u in this case, which actually limits the privileges of the created process and ties the tmux session to the proper user, what is the danger related to disallowing running beep?

Thanks.

Eventually, we should remove the console driver.

The console API is a pain permission-wise, uses completely unrelated filenames which you need to guess and try first.

Contrast that with the evdev API, where you have one device with a well-known name, and you can easily set its permissions using udev rules.

issue #6 might be a reason to delay this.

OTOH, we could get rid of a bit of code.