Выполнять как .test, а не ./test

или... возможно, дать интерпретатору псевдоним в файле 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.

Как было сказано в других, это может быть опасно, поэтому всегда будьте уверены. находится в конце ПУТИ, а не в начале.