Хорошо, я укушу. Вы используете команду 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
Чтобы вызвать программу по ее имени, оболочки ищут в каталогах в переменной среды $ 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 "$@"
Поскольку это имитирует переход в этот каталог и выполнение двоичного файла вручную, он упрощает отладку таких проблем, как несуществующие относительные пути.
Я редко видел программное обеспечение, которое поставляется в виде двоичного файла. исполняемый файл и ничего больше, и, честно говоря, я бы отнесся к нему с подозрением. По крайней мере, я ожидал бы, по крайней мере, README
(с инструкциями по его установке) и ЛИЦЕНЗИИ
, которые будут сопровождать его. При этом ...
Обычное место, где хранятся локально установленные двоичные файлы, не управляемые диспетчером пакетов дистрибутива, это / usr / local / bin
. Вы можете поместить его туда, и поскольку этот каталог уже есть (или должен быть) в вашем $ PATH
, вы можете запустить программное обеспечение, введя его имя в командной строке.
Обычно программное обеспечение также должно иметь справочную страницу (недокументированное программное обеспечение - это плохо, не так ли?), Которая находится в / usr / local / man
и может иметь некоторые вспомогательные файлы, такие как переводы на другие языки и плагины, которые может быть в / usr / local / share
или / usr / local / lib
и так далее. По этой причине программное обеспечение, которое не поставляется в виде пакета, например .deb
или .rpm
, обычно поставляется с установщиком, который помещает все в нужные места. Когда вы устанавливаете из исходного кода, это обычно make install
.
Вполне возможно и довольно просто создать двоичный пакет распространения из двоичного zip-архива или tarball, как в вашем примере с Visual Studio Код.
Да, двоичные пакеты дистрибутива Linux, такие как deb
s и rpm
s, обычно генерируются из исходного кода, но это не обязательно. И часто (хотя и не всегда) возможно сделать так, чтобы полученный двоичный пакет дистрибутива устанавливал вещи в «правильных» местах в соответствии с политикой распространения.
В случае случайного проприетарного архива, если был способ правильно установить программное обеспечение, например цель install в make-файле, которая затем может быть использована с механизмом упаковки дистрибутива. В противном случае это может потребовать «ручного» сопоставления файлов с «правильными» местами, что может потребовать много работы. Хотя создание такого пакета может показаться странным, он все равно будет иметь одно из основных преимуществ управления пакетами, а именно чистую установку и удаление.И, конечно же, такой пакет никогда не будет принят ни в один заслуживающий внимания дистрибутив Linux, но это не ваш вопрос.
Согласно 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
в этом случае, особенно если я не тот, кто создал программу, которую я устанавливаю.
ln -s </path/to/executable> /usr/local/bin/<program-name>
должно работать. Стандартное место для локального программного обеспечения — /opt
, поэтому я бы рекомендовал переместить туда папку/файл программного обеспечения перед его установкой с помощью приведенной выше команды.