Файлы журнала повреждены символами NUL и текстом из других процессов [дубликат]
Вам нужно запустить скрипт, а не использовать его:
/path/to/script.sh
(без . ).
Когда вы запускаете
. /path/to/script.sh
$0 - это ваша текущая оболочка, которая предположительно находится в /bin (отсюда и поведение, которое вы наблюдаете). Обратите внимание, что это не обязательно должно быть /bin/bash, шебанг не имеет никакого эффекта при использовании скрипта.
Lucas' остальные пункты верны, вы должны использовать кавычки и просто запустить dirname напрямую, без echo.
Чтобы немного расширить этот ответ , ваш системный журнал содержит содержимое страницы памяти, частично зафиксированной на диске, а метаданные системного журнала не обновлены. Эта строка из ^@символов на самом деле является байтами NUL; именно то, что изначально содержит только что выделенная страница памяти.
Содержимое файла системного журнала, которое вы показываете нам со всеми нулями, действительно является повреждением записи файловой системы/системного журнала.
Сбой вашей системы застал систему в середине -записи в файл системного журнала, и это конечный результат.
Уже видели, как это происходило несколько раз за эти годы, в виртуальных машинах Linux и еще пару раз в Raspberries и Banana Pis.
Нет ничего, что могло бы (слишком сильно )зацикливаться или терять много времени на выяснение, почему у вас есть это для одноразового -события. Я бы больше беспокоился, узнав, почему он разбился, особенно если это обычное событие.
PS Переходя к анекдотической территории, в прошлый раз, когда это происходило регулярно в Banana Pi R1, мне удалось отследить причину в (неисправном )чипсете Realtek Wi-Fi.