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

Хорошо, я укушу. Вы используете команду mv . Скажите, что вы находитесь в каталоге foo :

ls foo/*
foo/file1 foo/file2

foo/bar:

Теперь вы хотите переместить file1 и file2 из каталога foo в каталог foo / bar :

mv -v file1 file2 bar/
file1 -> bar/file1
file2 -> bar/file2

Результат:

ls foo
bar
ls foo/bar/
file1 file2

https://www.linux.com/learn/how-move-files -using-linux-commands-or-file-manager

13
24.02.2016, 10:43
5 ответов

Чтобы вызвать программу по ее имени, оболочки ищут в каталогах в переменной среды $ PATH . В Debian значение по умолчанию $ PATH для вашего пользователя должно включать / home / ВАШЕ-ИМЯ-ПОЛЬЗОВАТЕЛЯ / 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 "$@"

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

12
27.01.2020, 19:52

Я редко видел программное обеспечение, которое поставляется в виде двоичного файла. исполняемый файл и ничего больше, и, честно говоря, я бы отнесся к нему с подозрением. По крайней мере, я ожидал бы, по крайней мере, README (с инструкциями по его установке) и ЛИЦЕНЗИИ , которые будут сопровождать его. При этом ...

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

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

3
27.01.2020, 19:52

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

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

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

6
27.01.2020, 19:52

Согласно 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\"Program Name"), где 'package' - имя, описывающее пакет программ, а 'provider' - зарегистрированное в LANANA имя провайдера.

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

9
27.01.2020, 19:52

ln -s </path/to/executable> /usr/local/bin/<program-name> должно работать. Стандартное место для локального программного обеспечения — /opt, поэтому я бы рекомендовал переместить туда папку/файл программного обеспечения перед его установкой с помощью приведенной выше команды.

0
25.06.2020, 10:54

Теги

Похожие вопросы