Parsing of "-a" option does not follow common CLI conventions
hholst80 opened this issue · comments
This is still an issue.
I've just spent several hours making this wrong, and only after reading this I did come to realization there musn't be a space between `-a` and the device. Which is not what the `--help` says:
-a, --audio [DEVICE]
Originally posted by @pvalena in #12 (comment)
I'm using wf-recorder 0.4.1 and I can't reproduce this issue. I can run for example:
wf-recorder -a alsa_input.pci-0000_00_1f.3.analog-stereo
wf-recorder --audio alsa_input.pci-0000_00_1f.3.analog-stereo
Can you provide an example of command that doesn't work as expected?
[I] root@xps ~
# wf-recorder -a alsa_input.pci-0000_00_1f.3.analog-stereo -F scale=1920:-1,fps=30 -Cac3
selected region 0,0 0x0
Setting codec option: cpu-used=5
Setting codec option: deadline=realtime
Using video filter: scale=1920:-1,fps=30
[libvpx-vp9 @ 0x7f9c98003880] v1.13.1
[libvpx-vp9 @ 0x7f9c98003880] Neither bitrate nor constrained quality specified, using default CRF of 32
Setting codec option: cpu-used=5
Setting codec option: deadline=realtime
Choosing sample format fltp for audio codec ac3
Output #0, matroska, to 'recording.mkv':
Stream #0:0: Video: vp9, gbrp(pc), 1920x1080 [SAR 1:1 DAR 16:9], q=2-31
Stream #0:1: Audio: ac3, 48000 Hz, stereo, fltp, 192 kb/s
Using PulseAudio device: default
^C⏎ [I] root@xps ~
# wf-recorder -aalsa_input.pci-0000_00_1f.3.analog-stereo -F scale=1920:-1,fps=30 -Cac3
Output file "recording.mkv" exists. Overwrite? Y/n: y
selected region 0,0 0x0
Setting codec option: cpu-used=5
Setting codec option: deadline=realtime
Using video filter: scale=1920:-1,fps=30
[libvpx-vp9 @ 0x7f9274003880] v1.13.1
[libvpx-vp9 @ 0x7f9274003880] Neither bitrate nor constrained quality specified, using default CRF of 32
Setting codec option: cpu-used=5
Setting codec option: deadline=realtime
Choosing sample format fltp for audio codec ac3
Output #0, matroska, to 'recording.mkv':
Stream #0:0: Video: vp9, gbrp(pc), 1920x1080 [SAR 1:1 DAR 16:9], q=2-31
Stream #0:1: Audio: ac3, 48000 Hz, stereo, fltp, 192 kb/s
Using PulseAudio device: alsa_input.pci-0000_00_1f.3.analog-stereo
^C⏎ [I] root@xps ~
# wf-recorder --version
wf-recorder 0.4.0
[I] root@xps ~
#
ok, thanks. To clarify, the issue you are reporting is that that flag usage is unclear:
$ wf-recorder -a alsa_input.pci-0000_00_1f.3.analog-stereo
...
Using PulseAudio device: default
compared to:
$ wf-recorder -aalsa_input.pci-0000_00_1f.3.analog-stereo
...
Using PulseAudio device: alsa_input.pci-0000_00_1f.3.analog-stereo
The man page is a bit ambiguous on that. At the beginning it says:
-a, --audio [=DEVICE]
but later down it's correct:
To specify an audio device, use the --a<DEVICE> or ---audio=<DEVICE> options.
Probably updating (to clarify usage) the man page should be enough?
I think the convention is clear. Flags that does not take arguments can be passed together as a union. Say ps -auxf. In this case this should not be interpreted as -a option consuming the switches uxf but rather that all the flags auxf are enabled. If you want to send an option to a flag you specify that as the next following argument on the command line as argv+1. --foo=bar is a special syntax and one that I do like. but -afoo is just wrong, especially since -a foo will work, but silently drop the foo argument!
getopt and getopt_long is a mess with optional arguments, it might be possible to make this work as intended with optional arguments but I think the easiest solution is to just make -a options required and everything will work as intended with the POSIX API. perhaps if users want to be able to use the default audio system add an -A option that has that behavior? @ammen99
I don't really think this is problematic enough to warrant a breaking change in behavior. We could update the man page and the help section to be much more precise though (and maybe even explain the issue there) - that should be enough to get everyone going.
I am used to maintainers clinging on to their technical debt like it's their firstborn.
The right thing to do here is to fix the root cause of the problem, not to patch it up with documentation that nobody reads anyway. An application should be obvious.
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html#tag_12_02
Guideline 7:
Option-arguments should not be optional.
Another less invasive change would be to do my suggestion but the opposite switch. Use -a to enable default sound device (no options allowed, but since nobdy used that correctly anyway....) and use -A to specify an alternative sound device. The big question then is if -A should implicitly define -a as well? ;-)