© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
bbfa235
(Get the code!)
in comments from ubuntu-devel
[17:50] <juliank> Continuation lines seem wrong to have in that file
[17:50] <juliank> If you add a continuation line between 8.14 and 8.15, you can remove the continuation line again
[17:51] <juliank> A future update should probably handle that, but a continuation line here is not expected, and there's no point rolling it back as that's a non default unexpected thing
as stated clearly at
https:/
...
The file /etc/default/grub controls the operation of grub-mkconfig. It is sourced by a shell script, and so must be valid POSIX shell input; normally, it will just be a sequence of ‘KEY=value’ lines, but if the value contains spaces or other special characters then it must be quoted
...
per POSIX
https:/
Escape Character (Backslash)
A <backslash> that is not quoted shall preserve the literal value of the following character, with the exception of a <newline>. If a <newline> follows the <backslash>, the shell shall interpret this as line continuation. The <backslash> and <newline> shall be removed before splitting the input into tokens. Since the escaped <newline> is removed entirely from the input and is not replaced by any white space, it cannot serve as a token separator.
all that's to say that continuation lines are, and have been, supported in posix-shell-
that it's "non default unexpected thing" is specious ... at _best_ it's unused/untested by the pacakgers.
fwiw, with grub2-2.04 on numerous _other_ systems there are no problems whatsoever with these continuation lines; and Ubu 18LTS didn't either ... until 'recently'.
no, i don't yet have an identifying bisect ...
also, it's been commented that current bug is 'non-destructive'.
that's open to interpretation.
modifying an end-user config file persistently, and without user-interactio