Wykonaj jako .test zamiast ./test

Przypuśćmy, że jestem w tym samym folderze co plik wykonywalny, musiałbym wpisać to, aby go wykonać:

./file

Wolałbym nie pisać /, bo /trudno mi pisać.

Czy istnieje łatwiejszy sposób wykonania pliku? Idealnie po prostu prosta składnia, taka jak:

.file

lub coś innego, ale łatwiejsze niż wstawianie /tam postaci.

Być może istnieje jakiś sposób na umieszczenie czegoś w /binkatalogu lub utworzenie aliasu dla interpretera, aby móc użyć:

p file

Może to być „ryzykowne”, ale możesz po prostu mieć. w twojej ŚCIEŻCE.

Jak powiedziano w innych, może to być niebezpieczne, więc zawsze upewnij się. jest na końcu ŚCIEŻKI, a nie na początku.

.będzie automatycznie uzupełniać./ (pisać .i naciskać Tab) przynajmniej w nowoczesnych powłokach Bash, więc nie powinieneś używać złożonego lub niepewnego (jak PATHmodyfikacja) rozwiązania.

Jeśli nie zostanie ono automatycznie uzupełnione, może być konieczne zainstalowanie pakietu „bash-complete”.

lub ... może nadając tłumaczowi alias w pliku bashrc, a następnie po prostu

   p  file

Możliwe jest napisanie takiej funkcji:

p() {
 ./"$@"
}

w twoim ~/.bashrc. Wtedy będziesz mógł uruchomić p app argumentszamiast ./app arguments. To rozwiązanie działa dla plików wykonywalnych dowolnego typu, w tym skryptów i plików binarnych.

"$@"rozwija się do odpowiednio cytowanej listy argumentów przekazywanych do funkcji (zachowując wszystkie znaki specjalne przed rozszerzeniem globalnym lub zmiennym) i, jak wskazał @Scott, bashjest wystarczająco sprytny, aby ./przejść do pierwszego z nich, zachowując resztę.

Możesz umieścić .na swoim $PATH, dodając np. PATH=$PATH:.Do swojego /etc/profile, w ten sposób możesz wykonać filepo prostu pisząc file, chyba że znajduje się w innym folderze na twojej ścieżce (np /usr/bin/.). Pamiętaj, że generalnie nie jest to dobry pomysł.

Dlaczego jest źle: Powiedzmy, że znajdujesz się w sytuacji, w której nie ufasz w pełni zawartości katalogu - pobrałeś go z podejrzanego miejsca i chcesz to sprawdzić przed uruchomieniem, lub jesteś administratorem systemu pomagającym niektórym użytkownika, przeglądając katalog domowy itp. Chcesz wyświetlić katalog, więc spróbuj wpisać ls, ale ups, popełnisz literówkę i zamiast tego napisałeś sl. Autor tego szkodliwego katalogu przewidział to i umieścił w nim skrypt powłoki o nazwie „sl”, który uruchamia „rm -rf --no-preserve-root /” (lub coś bardziej złośliwego, jak instalowanie rootkita).

(Dzięki @Muzer za wyjaśnienie)

Możesz na przykład zadzwonić do tłumacza

bash test

W takim przypadku skrypt będzie działał, nawet jeśli nie będzie miał linii shebang (np. #!/bin/bash) Ani bitu wykonywalnego. Będziesz musiał znać poprawnego tłumacza, aby go uruchomić. Możesz najpierw przeczytać linię shebang pliku, aby upewnić się, że zadzwoniłeś do właściwego tłumacza, na przykład jeśli linia shebang mówi

#!/usr/bin/env python3

zadzwoniłbyś

python3 test

O ile mi wiadomo, nie ma sposobu na osiągnięcie tego, chyba że umieścisz plik w ścieżce env, więc możesz go uruchomić, wpisując: file

.filenie będzie działać, ponieważ jest to inna nazwa pliku. Jest to plik o nazwie .filei nie ./file.

Wyczuwam, że ukośnik może być dla ciebie trudny do napisania, ponieważ może nie w języku angielskim. W takim przypadku mi się to przydarza, więc często zamieniam układ klawiatury na angielski, naciskając Alt + Shift w systemie Windows (używam Linuksa z ssh)

Ludzie sugerują dodanie .do PATH, co jest niebezpieczne, ponieważ stwarza ryzyko, że przypadkowo uruchomisz złośliwy program umieszczony w katalogu do zapisu na całym świecie. Ale jeśli masz programy wykonywalne w kilku katalogach, które są właścicielami i zapisu tylko przez Ciebie, to jest to bezpieczne (dość bezpieczne?), Aby umieścić te reżyser (-a) się PATH, dodając taką linię

PATH=$PATH:~/dev/myprog1:~/dev/myprog2

do twojego ~/.bashrcpliku. Oczywiście oznacza to, że możesz uruchomić program z jednego z tych katalogów z dowolnego miejsca w systemie plików. Na przykład, możesz cd /etci pisz foo, a to się uruchomi ~/dev/myprog1/foo. Ma to niewielką wadę, że nie można mieć programów o tej samej nazwie w więcej niż jednym katalogu. W szczególności, jeśli masz programy wywoływane foo jednocześnie ~/dev/myprog1i ~/dev/myprog2nie będziesz mógł uruchomić drugiego, chyba że podasz ścieżkę. Podobnie, jeśli masz ~/dev/myprog1/cat- ale dlaczego chcesz?

Innym podejściem, jeśli masz tylko kilka programów, z którymi to robisz, jest zdefiniowanie dla nich aliasów:

alias gizmo='./gizmo'
alias gonzo='./gonzo'

Czy można nazwać aliasy .gizmoi .gonzo jeśli okaże się, że bardziej intuicyjne.

W rzeczywistości wiąże się to w pewnym stopniu z takim samym ryzykiem bezpieczeństwa, jak .w przypadku twojego PATH. Jeśli złośliwy użytkownik może odczytać .bashrci zobaczyć swoje aliasy, to może on umieścić złośliwego oprogramowania o nazwie gizmooraz gonzow przypadkowych katalogów, w nadziei, że będzie go uruchomić. Lepiej, aby używały bezwzględnych nazw ścieżek:

alias gizmo='~/dev/myprog1/gizmo'
alias gonzo='~/dev/myprog2/gonzo'

Nawiasem mówiąc, powinieneś unikać nazywania pliku wykonywalnego test, ponieważ jest to wbudowane polecenie powłoki, i możesz uruchomić program o tej nazwie tylko podając ścieżkę lub inną sztuczkę.

Aby rozwinąć odpowiedź Zanny na temat tłumaczy (przepraszam, brak komentarza dla komentarza): „tłumacz” dla natywnych plików wykonywalnych (czyli binarnych plików ELF) jest dynamicznym modułem ładującym ( ld.so), ale zazwyczaj nie rozumie pożądanej składni:

$ /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>

(także, chyba że dowiązujesz symbolicznie ld.sodo swojej ścieżki, nadal będziesz musiał napisać /s)

Jeśli wolno nam zacząć konfigurować

mkdir -p ~/.local/bin
cat > ~/.local/bin/x << 'EOF'
#!/bin/sh
N="$1"
shift
exec "./$N" "$@"
EOF
chmod a+x ~/.local/bin/x

Większość współczesnych dystrybucji zawiera już ~ / .local / bin w $ PATH (dodaj export PATH="$HOME/.local/bin:$PATH"do twojego, ~/.profilejeśli twój nie). Następnie możesz użyć x filedo uruchomienia ./file.

Nie próbuj definiować .polecenia. Polecenie . scriptdziała już scriptw bieżącej powłoce. Pozwala scriptto zdefiniować zmienne środowiskowe dla bieżącej powłoki.

Jeśli wolno nam tworzyć skrypty pomocnicze, możesz zrobić pomocnika, który doda PWD do ŚCIEŻKI, a następnie uruchom

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

Pozwala to uniknąć dodawania „.” do ścieżki i zanieczyszczając swój .profile każdą ścieżką, w której możesz chcieć coś uruchomić.

Możemy pójść o krok dalej, tworząc pomocnika, który uruchamia nową powłokę ze zmodyfikowaną ŚCIEŻKĄ. Jeśli bierze katalog jako parametr (używając domyślnie pwd), działałoby to tak, jakby pushdedytował ścieżkę. Być może będziesz musiał pamiętać, że wszelkie zmiany innych zmiennych środowiskowych zostaną utracone podczas wychodzenia z podpowłoki, ale w długo działającej powłoce twoja zmienna PATH nie będzie zaśmiecona. W zależności od przepływów pracy może to być korzystne.

:outer shell prompt$; subshellpathhelper    # launches a subshell with modified PATH
: subshell prompt $ ; file                  # in the subshell it can be run without ./

Ale myślę, że jeśli chce biegać z nim można siekać pushdi popdtak mogą zrobić te same modyfikacje ścieżki bez bez podpowłoce które stracą inne zmiany.

pushd --path ~/some/path/    # normal pushd plus adds target to path
file                         # it can be run without ./ until you popd

(Nie możesz zrobić tego samego, cdponieważ nie ma analogu do popd.)

Możesz także utworzyć dedykowaną parę pomocników, aby po prostu przesuwać i otwierać wpisy PATH. To, co działa najlepiej, zależy od wzorców użytkowania.

Możesz używać . script.shskładni, o ile skrypt, który chcesz wykonać, znajduje się w bieżącym katalogu.

Możesz także prefiksować za pomocą interpretera, np. Sh lub bash. przykład:bash script.sh