![В чем разница между копированием файла a.out (исполняемого файла) и установкой приложения?](https://rvso.com/image/898931/%D0%92%20%D1%87%D0%B5%D0%BC%20%D1%80%D0%B0%D0%B7%D0%BD%D0%B8%D1%86%D0%B0%20%D0%BC%D0%B5%D0%B6%D0%B4%D1%83%20%D0%BA%D0%BE%D0%BF%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5%D0%BC%20%D1%84%D0%B0%D0%B9%D0%BB%D0%B0%20a.out%20(%D0%B8%D1%81%D0%BF%D0%BE%D0%BB%D0%BD%D1%8F%D0%B5%D0%BC%D0%BE%D0%B3%D0%BE%20%D1%84%D0%B0%D0%B9%D0%BB%D0%B0)%20%D0%B8%20%D1%83%D1%81%D1%82%D0%B0%D0%BD%D0%BE%D0%B2%D0%BA%D0%BE%D0%B9%20%D0%BF%D1%80%D0%B8%D0%BB%D0%BE%D0%B6%D0%B5%D0%BD%D0%B8%D1%8F%3F%20.png)
В чем разница между установкой прикладного программного обеспечения и копированием исполняемого файла (например, a.out) приложения? Когда мы запускаем файл a.out, он дает какой-то результат, запуск установленного приложения также дает какой-то результат. Я не понимаю разницы, когда кто-то говорит «Установка приложения» и копирование исполняемого файла. Что на самом деле происходит при установке приложения? Чем это отличается от простого копирования исполняемого файла с одного компьютера на другой (та же ОС и похожее оборудование) и запуска его там?
решение1
Ну, когда говорятустановкаприложение, что обычно означает, что вы используете менеджер пакетов, например, dpkg
или семейство более высокого уровня apt
. В этом случае исполняемые файлы поставляются в пакете, который также может содержать дополнительные библиотеки, необходимые для запуска исполняемого файла, man-страницы, файлы разработчика, файлы конфигурации и т. д. Преимущество этого заключается в том, что администратор может отслеживать, что установлено, а также гарантировать, что при установке нового программного обеспечения или обновлений новое программное обеспечение не будет конфликтовать с другим программным обеспечением и библиотеками, уже установленными, что может привести к сбою других приложений.
Итак, хотя может сработать простое копирование исполняемого файла в другую систему, делать этого не рекомендуется, так как это может все сломать. Безопасно копировать исполняемые файлы куда-то за пределы системных путей, например /bin/
, /sbin
, /usr/bin
, , /usr/sbin
.
Вы можете использовать /usr/local/bin
и /usr/local/sbin
для этой цели или, что еще лучше, создать каталог ниже /opt
для исполняемого файла и поместить его туда. Затем вызовите исполняемый файл с полным путем или добавьте путь к исполняемому файлу в PATH
переменную среды.
$ mkdir -p /opt/myapp/bin
$ cp myexec /opt/myapp/bin/
$ /opt/myapp/bin/myexec
или
$ export PATH=$PATH:/opt/myapp/bin
$ myexec
решение2
Основной принцип всех Unix-подобных операционных систем (например, Ubuntu) заключается в следующем:все есть файл. Если вы посмотрите на содержимое пакета, вы также найдете там исполняемый файл, и да, для двух машин с абсолютно одинаковой (или, по крайней мере, очень похожей) комбинацией программного и аппаратного обеспечения (Платформа), вы могли бы просто использовать свой исполняемый файл. Но большинство программ не состоят только из одного исполняемого файла. Запустите ls -R /usr |grep libreoffice
для примера более сложный пакет, вы же не хотите копировать все эти файлы в их отдельные местоположения вручную сейчас, не так ли?
Хотя в некоторых случаях (особенно при тестировании небольших программ) имеет смысл просто отправить кому-то исполняемый файл, который он сможет запустить, почти всегда вам захочется предоставить пакет для готового продукта.
Менеджеры пакетов обычно также заботятся об установке зависимостей, добавляют вашу программу в список установленных приложений и PATH и, что не менее важно, предоставляют возможность обновить программу при выходе новой версии.