On 3/19/20 8:57 PM, Dimitri John Ledkov wrote: > Have you opened a launchpad bug report against the grub2 package with both > configs before and after? What is the bug number there? > > In general, we do parse and rewrite configs using debconf which is Perl / C > / Shell processing using tools external to grub. In general, we advise to > customize via grub.d drop-in files instead of modifying etc/default/grub > file itself. > > This is a bit out of scope for the upstream mailing list, as debconf > integration is downstream specific on Ubuntu/Debian systems. In general, other distros avoid parsing and rewriting configs because this should be the user's responsibility. :p
The OP should consider that maybe such distros are more stable than Ubuntu? ... Anyway, it seems clear-cut to me, as per the question which is NOT about what should be done with debconf. The OP's question is very simple: "Does the grub project consider /etc/default/grub as a shell-compatible file which is sourced, to be the PUBLIC INTERFACE of this configuration file?" It seems clear-cut to me. The quoted manual section explicitly documents that it is POSIX shell format, then calls out the idea of KEY=VALUE assignments and declares this to be *merely* "normally", thus highlighting the possibility that it isn't exclusively so. Compare this to, for example, the os-release(5) man page which states the following format for /etc/os-release: """ The basic file format of os-release is a newline-separated list of environment-like shell-compatible variable assignments. It is possible to source the configuration from shell scripts, however, beyond mere variable assignments, no shell features are supported (this means variable expansion is explicitly not supported), allowing applications to read the file without implementing a shell compatible execution engine. """ Note how os-release(5) explicitly goes to some lengths to declare the need for parsing this file in C, that it is *not* valid to simply use shell code, and then continues on to enumerate which subset of shell code it supports. The conclusion is simple enough: if you are going to automatically rewrite this grub file, you must do so using a parser engine that implements POSIX shell and knows how to properly tokenize and rewrite the full range of language features permitted by POSIX shell. Doing otherwise is YOLO, rash, buggy, and prone to breakage as demonstrated by the OP's bug report. If a downstream project making use of grub, then goes ahead and calls the use of backslash escapes for the very simple purpose of line continuation across multiple lines (of all the things one might do in a POSIX sh formatted configuration file, this is pretty tame), an issue of "highly unusual abuse of POSIX shell semantics", this is pretty bad I have to say. Also, it's victim blaming. Just my $0.02 as a distro person (not a grub dev). -- Eli Schwartz Arch Linux Bug Wrangler and Trusted User
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
