При перемещении файлов между файловыми системами mv
не удаляет файл, пока не закончит его копирование, а обрабатывает файлы последовательно (я изначально сказал, что он копирует, а затем удаляет каждый файл по очереди, но это не гарантируется - по крайней мере, GNU mv
копирует затем удаляет каждый аргумент командной строки по очереди, и POSIX определяет это поведение ). Таким образом, у вас должно быть не более одного неполного файла в целевом каталоге, а оригинал все еще будет в исходном каталоге.
Чтобы вернуть все назад, добавьте флаг -i
, чтобы mv
ничего не перезаписывал:
sudo mv -i ~/my_data_on_60GB_partition/* /media/admin/my_data/
(при условии, что у вас нет скрытых файлов для восстановления из ~ / my_data_on_60GB_partition /
) или еще лучше (учитывая, что, как вы обнаружили, у вас может быть много файлов, ожидающих удаления), добавьте флаг -n
, чтобы mv
ничего не перезаписывает, но не спрашивает вас об этом:
sudo mv -n ~/my_data_on_60GB_partition/* /media/admin/my_data/
Вы также можете добавить флаг -v
, чтобы увидеть, что делается.
Для любого POSIX-совместимого mv
исходная структура каталогов должна оставаться нетронутой, поэтому в качестве альтернативы вы можете проверить это - и просто удалить / media / admin / my_data
... (В общем случае я думаю, что вариант mv -n
является безопасным подходом - он обрабатывает все формы mv
, включая , например mv / media / admin / my_data / * my_data_on_60GB_partition /
.)
Возможно, вам потребуется восстановить некоторые разрешения; вы можете сделать это в массовом порядке , используя chown
и chmod
, или восстановить их из резервных копий, используя getfacl
и setfacl
(спасибо Сато Кацура за напоминание ).
или... возможно, дать интерпретатору псевдоним в файле bashrc, а затем просто
p file
Можно написать такую функцию:
p() {
./"$@"
}
в вашем ~/.bashrc
. Тогда вы сможете запускать p app arguments
вместо ./app arguments
. Это решение работает для исполняемых файлов любого типа, включая скрипты и двоичные файлы.
"$@"
расширяет список аргументов, переданных функции, до соответствующего кавычек (сохраняя все специальные символы от расширения glob или переменных), и, как заметил @Scott, bash
достаточно умен, чтобы добавить ./
к первому из них, сохраняя остальные.
Чтобы расширить ответ Занны об интерпретаторах (извините, нет комментариев для комментария): "интерпретатор" для собственных исполняемых файлов (также известный как двоичные файлы ELF) - это динамический загрузчик ( ld.so
), но обычно он не понимает желаемый синтаксис:
$ /usr/lib/ld-linux-x86-64.so.2 program
program: error while loading shared libraries: program: cannot open shared object file
$ /usr/lib/ld-linux-x86-64.so.2 ./program
<program is launched>
(также, если вы не укажете символическую ссылку ld.so
на свой путь,вам все равно нужно написать /
s)
Вы можете поместить .
в ваш $ PATH
, добавив, например, ПУТЬ = $ ПУТЬ :.
в ваш / etc / profile
, таким образом вы можете запустить файл
, просто написав файл
, если он не находится в какой-либо другой папке на вашем пути ( например, / usr / bin /
). Обратите внимание, что это, как правило, не очень хорошая идея.
Почему это плохо: допустим, вы находитесь в ситуации, когда вы не полностью доверяете содержимому каталога - вы загрузили его откуда-то подозрительно и хотите исследовать его перед запуском, или вы sysadmin помогает некоторым пользователям, просматривая их домашний каталог и т. д. Вы хотите перечислить каталог, поэтому вы пытаетесь ввести ls, но, к сожалению, вы допустили опечатку и вместо этого набрали sl. Автор этого вредоносного каталога предвидел это и поместил в него сценарий оболочки под названием "sl", который запускает 'rm -rf --no-preserve-root /' (или что-то более вредоносное, например, установка руткита).
(Спасибо @Muzer за объяснение)
Вы можете вызвать интерпретатор, например
bash test
. В этом случае скрипт будет запущен, даже если у него нет ни строки shebang (например, #! / bin / bash
), ни исполняемого бита. Вам также необходимо знать правильный интерпретатор, чтобы запустить его. Вы можете сначала прочитать строку shebang файла, чтобы убедиться, что вы вызываете правильный интерпретатор, например, если в строке shebang указано
#!/usr/bin/env python3
, вы должны вызвать
python3 test
.
автоматически заполнится до ./
(введите .
и нажмите Tab ), по крайней мере, в современных оболочках Bash, поэтому вам не нужно использовать сложное или небезопасное (например, модификация PATH
) решение.
Если автозаполнение не выполняется, вам может потребоваться установить пакет «bash-completion».
Вы можете использовать . script.sh
синтаксис до тех пор, пока сценарий, который вы хотите выполнить, находится в текущем каталоге.
Вы также можете использовать префикс интерпретатора, например sh или bash.
пример: bash script.sh
Если нам разрешено создавать вспомогательные сценарии, вы можете создать вспомогательный метод, который добавляет pwd в PATH, а затем запускает
. pathhelper #adds pwd to path
file #now it can be run without ./
Это позволяет избежать добавления "." к пути и загрязняют ваш .profile каждым путем, в котором вы можете в какой-то момент что-то запустить.
Мы можем пойти дальше в этом подходе, создав помощник, который запускает новую оболочку с измененным PATH. Если он принимает каталог в качестве параметра (используя pwd по умолчанию), он будет работать как pushd
, который редактирует путь. Возможно, вам придется помнить о том, что любые изменения в других переменных среды будут потеряны при выходе из подоболочки, но в долго работающей оболочке ваша переменная PATH не будет загромождена. В зависимости от ваших рабочих процессов это может быть выгодно.
:outer shell prompt$; subshellpathhelper # launches a subshell with modified PATH
: subshell prompt $ ; file # in the subshell it can be run without ./
Но я думаю, что если вы хотите работать с ним, вы можете взломать pushd
и popd
, чтобы они могли внести те же изменения в путь, не создавая подоболочку, которая потеряет другие изменения.
pushd --path ~/some/path/ # normal pushd plus adds target to path
file # it can be run without ./ until you popd
(Вы не можете сделать то же самое с cd
, потому что у него нет аналога popd
.)
Вы также можете создать пару специальных помощников для просто нажмите и вставьте записи PATH. То, что работает лучше всего, действительно зависит от ваших шаблонов использования.
Если нам разрешат начать настраивать вещи
mkdir -p ~/.local/bin
cat > ~/.local/bin/x << 'EOF'
#!/bin/sh
N="$1"
shift
exec "./$N" "$@"
EOF
chmod a+x ~/.local/bin/x
Большинство современных дистрибутивов уже включают ~/.local/bin в $PATH (добавьте export PATH="$HOME/.local/bin:$PATH"
в ~/.profile
, если в вашем нет). Затем вы можете использовать x file
для запуска ./file
.
Не пытайтесь определить
команду. Команда .script
уже запускает script
в текущей оболочке. Это позволяет script
определить переменные окружения для текущей оболочки.
Люди предложили добавить .
to PATH
,
что опасно, потому что создает риск
что вы случайно запустите вредоносную программу.
заложенную в каталог, доступный для записи в мире.
Но, если у вас есть исполняемые программы в нескольких каталогах.
которые принадлежат вам и доступны для записи только вам,
тогда безопасно (довольно безопасно?) поместить эти директории в PATH
,
добавив строку типа
PATH=$PATH:~/dev/myprog1:~/dev/myprog2
в ваш ~/.bashrc
файл.
Конечно, это означает, что вы можете запустить программу из одного из этих каталогов
из любого места в файловой системе.
Например, вы можете cd /etc
и набрать foo
,
и будет запущено ~/dev/myprog1/foo
.
Это имеет небольшой недостаток
что вы не можете иметь программы с одинаковыми именами
в более чем одном каталоге.
В частности, если у вас есть программы с именем foo
в каталогах ~/dev/myprog1
и ~/dev/myprog2
,
вы не сможете запустить второй, кроме как указав путь.
Аналогично, если у вас есть ~/dev/myprog1/cat
- но зачем вам это нужно?
Другой подход, если у вас всего несколько программ, с которыми вы это делаете, это определить для них псевдонимы:
alias gizmo='./gizmo'
alias gonzo='./gonzo'
Или вы можете назвать псевдонимы .gizmo
и .gonzo
если это кажется вам более интуитивным.
На самом деле, это в некоторой степени,
тот же риск безопасности, что и при установке .
в ваш PATH
.
Если злоумышленник может прочитать ваш .bashrc
и увидеть ваши псевдонимы,
то он может поместить вредоносное ПО под названием gizmo
и gonzo
в случайные каталоги.
в надежде, что вы их запустите.
Лучше сделать так, чтобы они использовали абсолютные пути:
alias gizmo='~/dev/myprog1/gizmo'
alias gonzo='~/dev/myprog2/gonzo'
Кстати, не следует называть исполняемый файл test
,
потому что это встроенная команда оболочки,
и вы можете запустить программу с таким именем
только указав путь или каким-то другим способом.
Насколько я знаю, этого невозможно достичь, если вы не включите файл в путь env, поэтому вы можете запустить его, просто набрав: file
.file
не будет работать, так как это другое имя файла. Это файл с именем .file
, а не ./ file
.
Я чувствую, что вам может быть сложно набрать косую черту из-за неанглийской раскладки, может быть? В этом случае такое случается и со мной, поэтому я часто меняю раскладку клавиатуры на английскую, нажимая Alt + Shift в Windows (я использую Linux из ssh)
Это может быть «рискованно», но можно было просто так. в вашем PATH.
Как было сказано в других, это может быть опасно, поэтому всегда будьте уверены. находится в конце ПУТИ, а не в начале.