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

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

./file

Я бы предпочел не печатать /, потому что /мне сложно печатать.

Есть ли более простой способ выполнить файл? В идеале это простой синтаксис, такой как:

.file

или что-то еще, но проще, чем вставлять /туда персонажа.

Возможно, есть какой-то способ поместить что-то в /binкаталог или создать псевдоним для интерпретатора, чтобы я мог использовать:

p file

Это может быть «рискованно», но вы могли бы просто иметь. в вашем ПУТИ.

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

.будет автоматически завершать./ (печатать .и нажимать Tab) по крайней мере в современных оболочках Bash, поэтому вам не нужно использовать сложное или небезопасное (например, PATHмодификационное) решение.

Если он не завершается автоматически, вам может потребоваться установить пакет «bash-complete».

или .. возможно, давая интерпретатору псевдоним в файле bashrc, а затем просто

   p  file

Можно написать такую ​​функцию:

p() {
 ./"$@"
}

в вашем ~/.bashrc. Тогда вы сможете бежать p app argumentsвместо ./app arguments. Это решение работает для исполняемых файлов любого типа, включая скрипты и двоичные файлы.

"$@"расширяется до надлежащим образом цитируемого списка аргументов, передаваемых функции (сохраняя все специальные символы из расширения glob или variable), и, как указал @Scott, bashдостаточно умен, ./чтобы присоединиться к первому из них, сохраняя остальные.

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

Почему это плохо: скажем, вы находитесь в ситуации, когда вы не полностью доверяете содержимому каталога - вы скачали его откуда-то изворотливо и хотите исследовать его перед запуском, или вы системный администратор, помогающий некоторым пользователя, просматривая его домашний каталог и т. д. Вы хотите перечислить каталог, поэтому вы пытаетесь набрать ls, но, к сожалению, вы сделали опечатку и в итоге вместо этого набрали sl. Автор этого вредоносного каталога предвидел это и поместил в него скрипт оболочки с именем «sl», который запускает «rm -rf --no-preserve-root /» (или что-то более вредоносное, например, установка руткита).

(Спасибо @Muzer за объяснение)

Вы можете позвонить переводчику, например,

bash test

В этом случае скрипт будет работать, даже если у него нет ни строки Шебанга (например #!/bin/bash), ни исполняемого бита. Вы должны будете знать правильный переводчик, чтобы запустить его также. Вы можете сначала прочитать строку shebang файла, чтобы убедиться, что вы вызываете правильный интерпретатор, например, если в строке shebang написано

#!/usr/bin/env python3

ты бы позвонил

python3 test

Насколько я знаю, нет способа достичь этого, если вы не включите файл в путь env, поэтому вы можете запустить его, просто набрав: file

.fileне будет работать, так как это другое имя файла. Это файл называется .fileи нет ./file.

Я чувствую, что слеш может быть трудно напечатать для вас, потому что не английский макет, может быть? В этом случае это также происходит со мной, поэтому я часто меняю раскладку клавиатуры на английский, нажимая Alt + Shift в Windows (я использую Linux из ssh)

Люди предложили добавить .к 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, потому что это встроенная команда оболочки, и вы можете запускать программу под этим именем только путем указания пути или другого трюка.

Чтобы расширить ответ Занны о интерпретаторах (извините, нет комментариев для комментария): «интерпретатор» для собственных исполняемых файлов (также называемых двоичными файлами 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)

Если мы можем начать настройку

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определять переменные среды для текущей оболочки.

Если нам разрешено создавать вспомогательные скрипты, вы можете создать помощника, который добавит pwd в PATH, а затем запустите

. pathhelper    #adds pwd to path
file            #now it can be run without ./

Это позволяет избежать добавления "." к пути и загрязнению вашего .profile каждым путем, который вы в какой-то момент захотите запустить.

Мы можем продвинуться к этому подходу, сделав помощника, который запускает новую оболочку с измененной переменной PATH. Если он принимает каталог в качестве параметра (используя pwd по умолчанию), он будет функционировать как a, 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. Что работает лучше всего, действительно зависит от ваших моделей использования.

Вы можете использовать . script.shсинтаксис, пока скрипт, который вы хотите выполнить, находится в текущем каталоге.

Вы также можете добавить префикс к интерпретатору, например, sh или bash. пример:bash script.sh