Hi Ville, On Sun, 23 Jul 2023 10:01:34 +0300, Ville Skyttä wrote: > On Sat, 22 Jul 2023 at 22:55, Ville Skyttä <ville.sky...@iki.fi> wrote: > [...] > > diff --git a/dmidecode.bash b/dmidecode.bash > [...] > > + -s | --string) > > + COMPREPLY=($(compgen -W ' > > + bios-vendor > > + bios-version > [...] > > Instead of duplicating the keywords here, these could be scraped from > `dmidecode --string` (without providing the keyword arg) output if > that sounds acceptable and the output is considered stable enough for > that purpose.
Yes, that output can be considered stable. I can't think of a reason to change its format in a foreseeable future. > Or let's say `--string help` could be implemented, and For name space reasons, I'd rather avoid that, although something like "--string ?" would be acceptable to me as "?" can't possibly be a valid string name. > it could print to stdout (no error), and only the keywords with no > error messages or header lines or the like if stdout is not a tty. I'd rather avoid testing stdout's type, both for portability reasons and to avoid confusion. I often test commands in a shell before including them in a shell script, and I hate when the command behaves differently once in the script. The rest is OK with me though. > Anyway, as it stands, with no modifications, could take all output > lines starting with whitespace from stderr. Ditto other keyword/type > lists across these completions. I'm fine either way. Duplicating the lists isn't necessarily that bad as they don't change often, but I understand that it's cleaner and easier to maintain to have it generated dynamically. And listing the keywords directly would obviously save some post-processing effort. Thanks, -- Jean Delvare SUSE L3 Support
