Package: nano Version: 3.2-3 Severity: normal Dear Maintainer,
when editing a UTF8 file in nano that contains a BOM (efbbbf) and inserting a character at the beginning, the BOM bytes will move after the inserted character. This can lead to breakages when such a file is being parsed by a programm as a BOM should, if at all present, only occur at the very beginning of the file. Ideally nano should detect the presence of BOM and not have it be editable/moveable. I've confirmed that this also affects version 4.9.3-1 as currently packaged in sid. The initial file with correct BOM: $ head -n 1 sample.ass | xxd 00000000: efbb bf5b 5363 7269 7074 2049 6e66 6f5d ...[Script Info] 00000010: 0a After inserting a leading space with nano: $ head -n 1 sample-nano.ass | xxd 00000000: 20ef bbbf 5b53 6372 6970 7420 496e 666f ...[Script Info 00000010: 5d0a ]. When doing the same with vim instead: $ head -n 1 sample-vim.ass | xxd 00000000: efbb bf20 5b53 6372 6970 7420 496e 666f ... [Script Info 00000010: 5d0a ]. I've attached an sample-file with correct and incorrect utf8 bom. Regards Nils -- System Information: Debian Release: 10.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (10, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.7.8-pc3+fs (SMP w/16 CPU cores) Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: openrc LSM: AppArmor: enabled Versions of packages nano depends on: ii libc6 2.28-10 ii libncursesw6 6.1+20181013-2+deb10u2 ii libtinfo6 6.1+20181013-2+deb10u2 ii zlib1g 1:1.2.11.dfsg-1 nano recommends no packages. Versions of packages nano suggests: pn spell <none> -- no debconf information
[Script Info]
[Script Info]
[Script Info]
