Да, это взаимодействие с дополнением.
Давайте посмотрим на фактически закодированные данные, расшифровав их, и (поскольку это не строка ASCII, )преобразуем их в двоичные данные:
$ base64 -d <<<'HelloWorld==' | xxd -b
00000000: 00011101 11101001 01100101 10100001 01101010 00101011 ..e.j+
00000006: 10010101 .
Это данные, для которых HelloWorld==
используется кодировка base64. Филип Коулинг объясняет тонкости декодирования последней части ld==
и то, что в некотором смысле только треть данных, закодированных с помощью d
, фактически используется при декодировании данных. Ниже я показываю, откуда появляется Q
, когда вы повторно -кодируете данные.
Повторим этот двоичный код:
00011101 11101001 01100101 10100001 01101010 00101011 10010101
В группах по шесть битов (, которые будет использовать кодировщик base64):
000111 011110 100101 100101 101000 010110 101000 101011 100101 01
Это дополнено четырьмя нулевыми битами в конце, чтобы получить 10 полных 6 -битовых кодов:
000111 011110 100101 100101 101000 010110 101000 101011 100101 010000
010000
— это Q
, которое вы видите при повторном -кодировании данных (см. таблицу кодов base64).
Я нашел решение, используя строку замены { #}, также известную как порядковый номер. Первый заголовок всегда будет в последовательности 1, поэтому мы можем обрабатывать его особым образом при разборе. Например со скриптом:
#!/bin/bash
_test()
{
if [[ "$1" == 1 ]]; then
:
else
cat
fi
}
export -f _test
parallel -a demo.txt -k --pipepart --will-cite _test {#}
Запуск этого скрипта дает ожидаемые результаты:
1
2
3
4
Ошибка исправлена в Git.
https://git.savannah.gnu.org/cgit/parallel.git/snapshot/parallel-master.tar.gz
parallel -a test.txt -k --pipepart --skip-first-line cat