В чем разница между копированием файла a.out (исполняемый файл) и установкой приложения? [закрыто]
В чем разница между установкой прикладного программного обеспечения и копированием исполняемого файла (например: a.out) приложения? Когда мы запускаем файл a.out, он дает некоторый результат, запуск установленного приложения также дает некоторый результат. Я не понимаю разницы, когда кто-то говорит «Установка приложения» и копирует исполняемый файл. Что на самом деле происходит при установке приложения? Как это отличается от простого копирования исполняемого файла с одного компьютера на другой (такого же os и аналогичного оборудования) и запускать его там?
4 ответа
Основной принцип всех Unix-подобных операционных систем (например, Ubuntu) - это все файл. Если вы посмотрите на содержимое пакета, вы также найдете там исполняемый файл и да, для двух машин с точно такой же (или, по крайней мере, очень похожей) комбинацией программного и аппаратного обеспечения (платформы) вы можете просто использовать свой исполняемый файл. Но большинство программ не состоят только из одного исполняемого файла. Запустите ls -R /usr |grep libreoffice для примера более сложного пакета, вы бы не захотели скопировать все эти файлы в своих отдельных местах вручную, не так ли?
Хотя в некоторых случаях (особенно при тестировании небольших программы) имеет смысл просто отправить кому-то исполняемый файл, который они могут запускать, вы почти всегда хотите предоставить пакет для готового продукта.
Менеджеры пакетов обычно также заботятся об установке зависимостей, добавляя свою программу к списку установленных приложений и PATH, и последнее, но не менее важное, возможность обновления программы при выпуске новой версии.
Хорошо, когда вы говорите об установке приложения, это обычно означает, что вы используете диспетчер пакетов, например dpkg или более высокий уровень apt. В этом случае исполняемые файлы отправляются в пакет, который также может содержать дополнительные библиотеки, которые необходимы для запуска исполняемого файла, manpages, файлов разработчиков, файлов конфигурации и т. Д. Преимущество этого заключается в том, что администратор может отслеживать, что установлено и также гарантирует, что при установке нового программного обеспечения или обновлений новое программное обеспечение не сталкивается с другим программным обеспечением и уже установленными библиотеками, что может привести к сбою других приложений.
Итак, хотя может работать только копирование поверх исполняемого файла к другой системе, это не рекомендуется, так как это может сломать вещи. Безопасно копировать исполняемые файлы куда-нибудь за пределы системных путей, таких как /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
Основной принцип всех Unix-подобных операционных систем (например, Ubuntu) - это все файл. Если вы посмотрите на содержимое пакета, вы также найдете там исполняемый файл и да, для двух машин с точно такой же (или, по крайней мере, очень похожей) комбинацией программного и аппаратного обеспечения (платформы) вы можете просто использовать свой исполняемый файл. Но большинство программ не состоят только из одного исполняемого файла. Запустите ls -R /usr |grep libreoffice для примера более сложного пакета, вы бы не захотели скопировать все эти файлы в своих отдельных местах вручную, не так ли?
Хотя в некоторых случаях (особенно при тестировании небольших программы) имеет смысл просто отправить кому-то исполняемый файл, который они могут запускать, вы почти всегда хотите предоставить пакет для готового продукта.
Менеджеры пакетов обычно также заботятся об установке зависимостей, добавляя свою программу к списку установленных приложений и PATH, и последнее, но не менее важное, возможность обновления программы при выпуске новой версии.
Хорошо, когда вы говорите об установке приложения, это обычно означает, что вы используете диспетчер пакетов, например dpkg или более высокий уровень apt. В этом случае исполняемые файлы отправляются в пакет, который также может содержать дополнительные библиотеки, которые необходимы для запуска исполняемого файла, manpages, файлов разработчиков, файлов конфигурации и т. Д. Преимущество этого заключается в том, что администратор может отслеживать, что установлено и также гарантирует, что при установке нового программного обеспечения или обновлений новое программное обеспечение не сталкивается с другим программным обеспечением и уже установленными библиотеками, что может привести к сбою других приложений.
Итак, хотя может работать только копирование поверх исполняемого файла к другой системе, это не рекомендуется, так как это может сломать вещи. Безопасно копировать исполняемые файлы куда-нибудь за пределы системных путей, таких как /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