Thanks for the review!

Remove gnu directories and add non-tracked ones

Fix style.

Use one single if statement.

Reuse variable in error message.

Remove comments

In D59621#1372603, @christos wrote:

Also I don't hit the error your test plan shows on 15.0-RELEASE:

$ kldstat | grep cuse
 5    1 0xffffffff84148000     6710 cuse.ko
$ virtual_oss
virtual_oss: Could not connect to cuse module

Thanks for the review!

Use variable instead of hardcoded name.

In D32297#1367860, @ziaee wrote:

Currently the OS is shown in manpage header and footer. The patch would make it shown only in the footer, and make the header the same as on other OSes. Should we do this, or close this revision?

Thanks for the review!

Use PORTSDIR and default to /usr/ports if empty.

Try and fix leak issue.

Address feedback by ngie@

In D51683#1359560, @ngie wrote:

This change seems like it would cause further confusion.
The Linux [coreutils'] version of su uses -g for overriding the primary group and -G to specify the supplementary group: https://www.man7.org/linux/man-pages/man1/su.1.html .
In an ideal world, I honestly think it would be best to rename -c to -C for symmetry with other utilities, but I'm sure that would cause loads of teeth gnashing and complaining from folks since -c has meant "class" since 1997 (renaming the option would break UX for a lot of scripts).
-C seems appropriate here, if nothing else... but I'm not sure this change is necessary. What issue are you ultimately trying to solve and what lead you to this conclusion?

Thank you very much for the review!

Remove spurious string copy.

Ping! 🔔

Friendly ping! 🔔

Fast exit on unknown device

Improve message for wrong pcm device numbers

Remove error msg about unit number being negative

In D56845#1352108, @christos wrote:

In D56845#1349251, @fernape wrote:

I would argue that the user might not know it. "Invalid argument" is barely descriptive IMHO. If mixer knows the problem is that the supplied device number is negative, why not tell the user the exact problem instead of trusting the user "should know" something?

The reason I'm pushing back against this is because, apart from the fact that the -d option is already documented in the man page, the logic of the option is that you supply the name of the device (e.g., pcm0) or just its unit number. The error messages you introduce are accurate in the sense that they are more fine-grained in an input sense, but the point is that the user is trying to reference a device that does not exist, and these messages in my opinion make the issue more about the fact that the numbers are negative/out of range/etc, and not about the fact that the device simply does not exist. That's why I think "Invalid argument" for example is enough, because if someone deliberately tries to use the -d option, they should know what arguments it expects also, they wouldn't use an option randomly.

In D56845#1348954, @christos wrote:

To be fair, I don't think these changes are meaningful. mixer(8) will fail for all the cases you are trying to catch anyway, and I think the messages are clear enough already.

Negative dunit:

$ mixer -d -1
mixer: cannot set default unit to -1: Invalid argument

dunit larger than the total number of mixers:

$ mixer -d10
mixer: cannot set default unit to 10: Invalid argument

Too large number:

$ mixer -d9999999999999999999999
mixer: strtol(9999999999999999999999): Result too large

Invalid input:

$ mixer -dfoobar
mixer: strtol(foobar): Invalid argument

The current scheme is uniform, and if a user wants to use the -d option in the first place, they should know that the argument is supposed to be a unit number (or pcm<unit_number>), so the current messages point to what the error is pretty well IMHO.

Friendly ping 🔔 !!

LGTM!