Как установить исполняемые файлы

Я иногда сталкиваюсь с программным обеспечением, которое не предлагается .debили .rpmтолько как исполняемый файл.
Например, Visual Studio Code , WebStorm или Kerbal Space Programm .

Для этого вопроса я возьму Visual Studio Code в качестве ориентира.

Программное обеспечение предлагается в виде упакованного пакета.
При распаковке у меня остается папка с именем, VSCode-linux-x64которая содержит исполняемый файл с именем Code.
Я могу дважды щелкнуть Codeили указать на него с помощью моего терминала, как /home/user/Downloads/VSCode-linux-x64/Codeвыполнить его.
Тем не менее, я хотел бы знать, если есть правильный способ установки этого приложения.

Чего я хочу достичь:

• одно место, где я могу разместить все приложения / программы, которые предлагаются таким образом (исполняемые файлы)
• поддержка терминала (это означает, например: я могу писать vscodeиз любой папки в моем терминале, и он автоматически выполнит код Visual Studio.

Дополнительная информация:

• Окружение рабочего стола: Gnome3
• ОС: Debian

РЕДАКТИРОВАТЬ:
Я решил дать @kba ответ, потому что его подход лучше работает с моим решением для резервного копирования и, кроме того. Наличие скрипта, исполняющего двоичные файлы, дает вам возможность добавлять аргументы.
Но, честно говоря, подход @Джон В.Х. Смита так же хорош, как и подход @ kba.

Чтобы вызвать программу по ее имени, оболочки ищут каталоги в $PATHпеременной окружения. В Debian значение $PATHпо умолчанию для вашего пользователя должно включать /home/YOUR-USER-NAME/bin(т.е. ~/bin).

Сначала убедитесь, что каталог ~/binсуществует, или создайте его, если его нет:

mkdir -p ~/bin

Вы можете использовать символьные ссылки на этот каталог, чтобы сделать его доступным для оболочки:

mkdir -p ~/bin
ln -s /home/user/Downloads/VSCode-linux-x64/Code ~/bin/vscode

Это позволит вам запускаться vscodeиз командной строки или из командной строки.

Примечание. Вы также можете копировать двоичные файлы в $PATHкаталоги, но это может вызвать проблемы, если они зависят от относительных путей.

В целом, тем не менее, всегда предпочтительно правильно устанавливать программное обеспечение, используя средства, предоставляемые ОС (apt-get, deb пакеты) или инструменты сборки программного проекта. Это обеспечит правильную настройку зависимых путей (таких как стартовые скрипты, справочные страницы, конфигурации и т. Д.).

Обновление: также отражает комментарии Томаса Дики и ответ Фахима Митхи о том, что я обычно делаю для программного обеспечения, которое поставляется в виде архива с бинарным файлом верхнего уровня и ожидает запуска оттуда:

Положите его в месте вменяемого (в порядке стандартов соответствия /opt, /usr/localили папку в вашем домашнем каталоге, например ~/build) и создать исполняемый скрипт - обертку в $PATHместе (например , /usr/local/binили ~/bin) , что изменения в это место и выполняют двоичное:

#/bin/sh
cd "$HOME/build/directory"
exec ./top-level-binary "$@"

Поскольку это эмулирует переход в этот каталог и выполнение двоичного файла вручную, это облегчает отладку таких проблем, как несуществующие относительные пути.

Согласно TLDP , это /optможет быть хорошим местом для такого рода программного обеспечения. Я сам использовал его для хранения некоторых инструментов, связанных с принтером, и «динамической» версии Skype (как сказал kba, «поддержка терминала» может быть достигнута путем соответствующей установки PATHпеременной).

В более общем смысле, я склонен использовать /optдля «установки» проприетарное программное обеспечение, упакованное как исполняемый файл, но это, вероятно, только я. Кроме того, я склонен просто избегать такого рода программного обеспечения, поскольку у меня обычно нет уверенности в том, что он собирается делать после запуска.

Другая причина, по которой я выбрал, /optзаключается в том, что он обычно предназначен для стороннего независимого кода, который не зависит ни от какого файла за пределами своего /opt/'package'каталога (и других optкаталогов, таких как /etc/opt).

Ни при каких обстоятельствах другие файлы пакетов не должны существовать вне иерархий / opt, / var / opt и / etc / opt, за исключением тех файлов пакетов, которые должны находиться в определенных местах в дереве файловой системы, чтобы функционировать должным образом. [...] Как правило, все данные, необходимые для поддержки пакета в системе, должны присутствовать в / opt / 'package', включая файлы, предназначенные для копирования в / etc / opt / 'package' и / var / opt / ' package ', а также зарезервированные каталоги в / opt.

Одним из преимуществ выпуска исходного кода является то, что люди могут настраивать процесс компиляции, предоставляя собственные пути к библиотекам / заголовкам в зависимости от особенностей своей системы. Когда разработчик решает выпустить код как исполняемый файл, это преимущество теряется. ИМХО, на этом этапе разработчику больше не разрешается предполагать, что зависимости его / ее программы будут доступны (именно поэтому все должно быть упаковано вместе с исполняемым файлом).

Любой устанавливаемый здесь пакет должен размещать свои статические файлы (например, дополнительные шрифты, картинки, файлы базы данных) в отдельном дереве каталогов / opt / 'package' или / opt / 'provider' (аналогично тому, как Windows будет устанавливаться). новое программное обеспечение в собственном дереве каталогов C: \ Windows \ Progam Files \ «Имя программы»), где «пакет» - это имя, которое описывает пакет программного обеспечения, а «поставщик» - это зарегистрированное имя провайдера LANANA.

Для получения дополнительной информации, я бы также предложил прочитать этот другой вопрос U & L , который касается различий между /optи /usr/local. Я бы лично избегал /usr/localв этом случае, особенно если я не тот, кто создал программу, которую я устанавливаю.

Вполне возможно, и на самом деле довольно просто, создать дистрибутивный двоичный пакет из двоичного zip-архива или архива, как в вашем примере кода Visual Studio.

Да, бинарные пакеты дистрибутива Linux, такие как debs и rpms, обычно генерируются из исходного кода, но это не обязательно. И часто (хотя и не всегда) можно устроить так, чтобы получающийся двоичный пакет распространения устанавливал вещи в «правильных» местах, чтобы соответствовать политике распространения.

В случае случайного проприетарного архива, если был способ правильно установить программное обеспечение, например, цель установки в make-файле, то это можно было бы использовать с механизмом распространения пакетов. В противном случае, это может привести к «ручному» отображению файлов в «правильные» места, что может быть большой работой. Хотя создание такого пакета может показаться странным, у него все равно будет одно из основных преимуществ управления пакетами, а именно чистая установка и удаление. И, конечно, такой пакет никогда не будет принят ни в одном дистрибутиве Linux, достойном названия, но это не ваш вопрос.

Я редко видел программное обеспечение, которое поставляется в виде двоичного исполняемого файла и ничего более, и я бы, честно говоря, немного подозрительно относился к нему. Если ничего другого, я бы по крайней мере ожидал README(с инструкциями по его установке) и a, LICENSEчтобы сопровождать его. Что, как говорится...

Обычное место, где хранятся локально установленные двоичные файлы, не управляемые менеджером пакетов дистрибутива, это /usr/local/bin. Вы можете поместить его туда, и так как этот каталог уже (или должен быть) уже в вашем, $PATHвы можете запустить программное обеспечение, введя его имя в командной строке.

Обычно в программном обеспечении также должна быть справочная страница (недокументированное программное обеспечение - это плохо, верно?), Которая входит /usr/local/manи может иметь некоторые вспомогательные файлы, такие как переводы на другие языки и плагины, которые могут входить /usr/local/shareили /usr/local/lib, и так далее. По этой причине программное обеспечение, которое не поставляется в виде пакета, такого как .debили .rpmобычно поставляется с установщиком, который размещает все в нужных местах. Когда вы устанавливаете из источника, это обычно make install.