Исходный файл содержит строку, оканчивающуюся на CR/LF. CR передается как часть переменной $PROJECT
, а поскольку CR является допустимым символом в имени файла, все промежуточные шаги работают правильно. (Но имена файлов "неправильные".)
Последний вывод также правильный, но CR в имени файла интерпретируется как принудительное возвращение курсора в начало строки, поэтому все, что вы видите, это _selected_Bif
.
Вы можете доказать это, удалив CR при чтении содержимого файла.
ROT13 сдвигает алфавит на 13 позиций, так что A и N меняются местами, как и B и O, и так далее. Он не переворачивает алфавит, как это делают ваши попытки.
Синтаксис tr
может немного запутывать это действие. Кодировщик/декодер ROT13, который вы опубликовали, можно было бы написать так, чтобы было немного понятнее, что происходит:
tr 'A-MN-Za-mn-z' \
'N-ZA-Mn-za-m' \
<<< ciphertext
Здесь вы можете немного лучше увидеть, как соответствующие диапазоны букв соотносятся друг с другом.
tr 'A-MN-Za-mn-z' 'N-ZA-Mn-za-m'
, возможно, работало 50 лет назад, но больше не работает с 1992 года, когда в UNIX была введена интернационализация.
Проверить:
$ echo Gur cnffjbeq vf 5Gr8L4qetPEsPk8htqjhRK8XS | /usr/xpg4/bin/tr 'A-MN-Za-mn-z' 'N-ZA-Mn-za-m'
выводит (в зависимости от фактической локали ), например.:
vFè pÂÛÛAøßé ÌÛ 5vè8À4éßËEtêEá8VËéAVÈÁ8jÊ
Почему это происходит?
Причина в том, что диапазон N-Z
содержит более 13 символов, например. Ö
, Ü
,... и в результате при использовании реализации tr
, которая правильно реализует сортировку, единственный способ правильно указать rot13 работает с использованием:
tr ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz NOPQRSTUVWXYZABCDEFGHIJKLMnopqrstuvwxyzabcdefghijklm