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.
