On Fri 26 Apr 2024 at 11:27:24 (+0900), John Crawley wrote:
On 24/04/2024 22:37, David Wright wrote:
On Wed 24 Apr 2024 at 14:50:36 (+0200), Richard wrote:
upon gathering my thoughts for answering to you I found the solution to this: update-initramfs can't handle the case that crypttab ends in the line
of the last entry and not in a new line character. I think there either should be a fix for this or at least a way to handle this case with a much
clearer error message. So I'll probably open a bug report for the package and the maintainer can decide if that should be forwarded upstream. Such a
rather trivial case shouldn't be resulting in such fatal errors.
Some time at the end of the last century, I remember some startup script that cat'd its configuration file for that very reason. It taught me
the habit of always finishing files with a blank comment line:
$ cat /etc/crypttab
# <target name> <source device> <key file> <options>
swap LABEL=cryptswap /dev/urandom swap,offset=2048,cipher=aes-xts-plain64,size=512
#
$
Innocent question: what difference does the comment make vs just ending the file with an empty line?
Nothing for the computer, but visibility for me.
Say you print the file on paper. All you see is white space after
the end of the printed text. Is there an empty line?
Or take, for instance, my example above, and think back to those VDUs,
as we called them, where the firmware added a newline as soon as the
cursor reached the right side of the screen, without waiting to see
whether the next character was itself a newline or not.¹ So using an
empty line approach, you might find yourself looking at a screen like:
Last character position on the screen -----------------------↓
swap LABEL= … … … … … … … … … … … … … … … … … … … … … =512
$
Now, is that an empty line before the prompt, or did the terminal
add the extra newline itself because the swap line was exactly
80 characters long?
Editor examples: a windowed emacs buffer has a ≣ decoration at the
extreme left edge after the last line of text, so that you can
distinguish an absence of lines from empty lines. However, a
non-windowed emacs in an xterm has no such decoration: you have to
provoke an "end of buffer" message to be certain where the file ends.
And nano is worse: to know you've reached the bottom, you have to
check the cursor doesn't advance when you pound on the downarrow key.
¹ IIRC, there's a terminfo capability, am, to work around this.
Cheers,
David.
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)