Виконати як .test, а не ./test

Припустимо, я перебуваю в тій самій папці, що і виконуваний файл, мені потрібно буде ввести це для його виконання:

./file

Я б краще не вводив /, тому що /мені важко набрати.

Чи є простіший спосіб виконання файлу? В ідеалі просто простий синтаксис, наприклад:

.file

або щось інше, але простіше, ніж там, щоб вставити /символ.

Можливо, є якийсь спосіб помістити щось у /binкаталог або створити псевдонім для перекладача, щоб я міг використовувати:

p file

Це може бути "ризиковано", але ви могли просто мати. у вашій ПАТІ.

Як було сказано в інших, це може бути небезпечно, тому завжди слід переконатися. знаходиться в кінці ПАТ, а не на початку.

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

Якщо вона не завершиться автоматично, можливо, вам доведеться встановити пакет "bash-завершення".

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

   p  file

Можна записати таку функцію:

p() {
 ./"$@"
}

у вашому ~/.bashrc. Тоді ви зможете працювати p app argumentsзамість цього ./app arguments. Це рішення працює для виконуваних файлів будь-якого типу, включаючи сценарії та бінарні файли.

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

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

Чому це погано: Скажіть, ви потрапили в ситуацію, коли ви не повністю довіряєте вмісту каталогу - ви завантажили його звідки-небудь хитромудрі, і ви хочете дослідити його, перш ніж запустити його, або ви сисадмін, який допомагає деяким користувач, заглянувши в його домашній каталог і т. д. Ви хочете перерахувати каталог, тому ви намагаєтеся ввести ls, але, ой, ви робите помилку на друку і в кінцевому підсумку набираєте напис sl. Автор цього шкідливого каталогу передбачив це і вклав у нього скрипт оболонки під назвою "sl", який виконує "rm -rf --no -serve-root /" (або щось більш шкідливе, як встановлення rootkit).

(Дякую @Muzer за пояснення)

Ви можете зателефонувати перекладачеві, наприклад

bash test

У цьому випадку сценарій запускається, навіть якщо він не має ані рядки shebang (наприклад #!/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, тому що це команда, вбудована в оболонку, і ви можете запустити програму під цим ім'ям, лише вказавши шлях або якийсь інший трюк.

Щоб розширити відповідь Zanna про інтерпретаторів (вибачте, немає коментаря для коментаря): "інтерпретатор" для власних виконуваних файлів (aka binary файли 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на свій шлях, вам все одно потрібно буде записати /)

Якщо нам дозволяють розпочати налаштування речей

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 за замовчуванням), він буде функціонувати так, як 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