Внимание, сейчас будем упарываться. Давно не упарывались. Камон в нашу ламповую лабораторию. Сразу не сбегай, возможно узнаешь что-то новенькое или окончательно засвистит фляга.
Для начала давай создадим две подопытные папки:
mkdir /tmp/{.libs,.bashdays}
Теперь скопируем в них нативную утилиту cp (copy):
cp "$(which cp)" /tmp/.libs/lt-test
cp "$(which cp)" /tmp/.bashdays/lt-test
Скопировали, файлы назвали lt-test.
Далее запускаем:
/tmp/.libs/lt-test example.txt .
В параметрах указываем файл, которого нет. На экран вывелось:
test: cannot stat 'example.txt': No such file or directory
А теперь запускаем:
/tmp/.bashdays/lt-test example.txt .
На экран получаем:
/tmp/.bashdays/lt-test: cannot stat 'example.txt': No such file or directory
Ну и внимательно сравниваем результаты:
1. test: cannot stat 'example.txt'
2. /tmp/.bashdays/lt-test: cannot stat 'example.txt'
Хм, всё же идентично, почему тогда результаты разные? В первом случае кусок названия запускаемого файла lt-test вообще обрезан.
В первом случае путь и префикс lt был обрезан, потому что запуск утилиты был выполнен из директории .libs.
Всё дело в функции set_program_name которую пихают в ГНУтые утилиты и программы. Эта функция модифицирует путь и имя утилиты если запуск был произведен из папки .libs, а затем присваивает результат переменным.
А потом эти переменные используются для вывода при ошибках или при выводе страницы хелпа.
Ну и на закуску тест:
/tmp/.libs/lt-test --help | head -1
/tmp/bashdays/lt-test --help | head -1
Результат тот же:
1. bash: /tmp/.libs/lt-test --help
2. bash: /tmp/bashdays/lt-test --help
Как это обрабатывается на самом деле, можешь глянуть в нативном исходнике на СИ здесь, там и про префикс lt и про .libs всё прекрасно структурировано. А здесь можешь ознакомиться с развёрнутым комментарием на эту же тему.
Короче голову не грей, на этой неделе постараюсь подобным тебя больше не развлекать. Спасибо за внимание!
Комментарии