Good modern terminals support bracketed paste: when you use the terminal's paste command, it sends special escape sequences around the clipboard content. If your shell supports bracketed paste, it'll paste the clipboard content including any control characters as-is, and in particular a trailing newline will not trigger the execution of the command.
Zsh ≥5.1 supports bracketed paste and has it on by default. Older versions can be taught. Bash ≥4.4 supports bracketed paste if you add set enable-bracketed-paste on to ~/.inputrc.
If your terminal or shell doesn't support bracketed paste, you could define a shell function that pastes without the trailing newline.
In zsh, the following command recalls the content of the clipboard, minus trailing newlines, and brings it up for editing (even if there are multiple lines):
print -z -- "`xsel -b`"
In bash, you can push the content of the clipboard minus trailing newlines to the history stack. After this, press Up to bring up the command for editing.
history -s -- "`xsel -b`"
The number of spaces is a way to cosmetically separate the columns/fields. It has no meaning other than that. I.e. no the amount of white space between columns does not matter.
The space between columns is comprised of white space (including tabs), and the columns themselves, e.g. comma-separated options, mustn't contain unquoted white space.
From the fstab(5) man page:
[...] fields on each line are separated by tabs or spaces.
and
If the name of the mount point contains spaces these can be escaped as `\040'.
Example
With the following lines alignment using solely a single tab becomes hard to achieve. In the end the fstab without white space looks messier than what you consider disconcerting now.
/dev/md3 /data/vm btrfs defaults 0 0
/var/spool/cron/crontabs /etc/crontabs bind defaults,bind
//bkpsrv/backup /mnt/backup-server cifs iocharset=utf8,rw,credentials=/etc/credentials.txt,file_mode=0660,dir_mode=0770,_netdev
Can you still see the "columns"?
Best Answer
A line is a sequence of characters terminated by a newline character. The characters that appear after the last newline of a file are not part of a line.
Such a file that has characters after the last newline is not a text file as per the POSIX definition of a text file, and the behaviour of text utilities is unspecified in that case and in practice, behaviour varies:
sed)cut)readwhich returns a non-zero exit status when reading a non terminated line.So even if the
mount,swapon,fsck... utilities (those which typically read /etc/fstab) understand non-terminated lines, some script that process that file may still fail. You should always make sure text files are terminated by a newline character (unless they're empty). Text editors should do that by default. You generally need to go through hoops to remove that last newline characters.