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 /bin
katalogu lub utworzenie aliasu dla interpretera, aby móc użyć:
p file
filenames
executable
IMSoP
źródło
źródło
/
jest szeroko stosowany w Uniksie, głównie jako separator katalogów. Prawdopodobnie lepiej jest znaleźć łatwiejszy sposób na wpisanie go./
dla większości ludzi nie jest trudne do pisania, a jeśli OP dozna obrażeń, które temu zapobiegają, powinni rozważyć alternatywne układy klawiatury, ponieważ nie ma możliwości, aby/
całkowicie uniknąć, gdy są w terminalu./
z shift-7, którego pisanie jest stosunkowo trudne, nawet bez urazu.Odpowiedzi:
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.
źródło
cd
do katalogu, w którym można zapisywać na całym świecie, i spróbujesz użyć polecenia, które nie jest na twojej ścieżce, możesz wykonać (prawdopodobnie złośliwy) plik wykonywalny o tej samej nazwie, który ktoś napisał na tę ścieżkę. Jest to o wiele gorsze, jeśli umieścisz.
na początku swojej ścieżki. W takim przypadku złośliwy plik wykonywalny o nazwiels
zostanie wykonany, jeśli spróbujesz zadzwonićls
do tego katalogu.p
Komenda będzie lepiej..
początkuPATH
szkodliwy użytkownik musi jedynie umieścić fałszywels
polecenie w swoim katalogu i przekonać administratora, aby „spojrzał na coś dziwnego” i ma dostęp do konta root.test
, tak jak w tytule pytania (ponieważtest
jest to wbudowana powłoka i prawdopodobnie istnieje już gdzieś w twoim pliku$PATH
)..
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 (jakPATH
modyfikacja) rozwiązania.Jeśli nie zostanie ono automatycznie uzupełnione, może być konieczne zainstalowanie pakietu „bash-complete”.
źródło
.
ma wiele kandydatów do uzupełnienia:.
(aktualny katalog), (katalog..
macierzysty),.
polecenie (dla którego bash zapewnia niestandardowy aliassource
) oraz wszelkie obecne pliki dot. Możebash-completion
pakiet ignoruje to; Uważam, że jest to okropnie denerwujące (np. Uniemożliwia uzupełnianie nazw katalogów tabulatorem wmake
wierszu poleceń i ogólnie jest okropne z plikami makefile zawierającymi niejawne reguły), więc zawsze go usuwam.make
celów.Możliwe jest napisanie takiej funkcji:
w twoim
~/.bashrc
. Wtedy będziesz mógł uruchomićp app arguments
zamiast./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,bash
jest wystarczająco sprytny, aby./
przejść do pierwszego z nich, zachowując resztę.źródło
strace -f p app
wyświetlanie wywołań systemowych lub$(which time) p app
sprawdzanie, jak długo to trwa.p
ponieważ skrypt wykonywalny działałby lepiej w tych dwóch konkretnych przykładach, które wymyśliłem. Żadne z tych rozwiązań nie może działaćldd p app
, chociaż różni sięldd
również wymaganiem pełnej ścieżki, być może z takich powodów.p app args
go./app args
w sposób niewidoczny dla każdego wymagałoby przepuszczenia danych wejściowych powłoki przez jakiś preprocesor i spowodowałoby wszelkiego rodzaju zabawę, gdy podstawienie nastąpiło w niezamierzonym miejscu :)$@
? W przeciwnym razie przekaże programowi tylko jeden duży argument.$@
to tablica. Po rozwinięciu"
każdy parametr rozwija się do osobnego słowa.$*
zachowuje się tak, jak myślisz.p() { ./"$@"; }
to wszystko, czego potrzebujesz.Możesz umieścić
.
na swoim$PATH
, dodając np.PATH=$PATH:.
Do swojego/etc/profile
, w ten sposób możesz wykonaćfile
po prostu piszącfile
, 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)
źródło
Możesz na przykład zadzwonić do tłumacza
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ówizadzwoniłbyś
źródło
/lib/ld.so
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
.file
nie będzie działać, ponieważ jest to inna nazwa pliku. Jest to plik o nazwie.file
i 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)
źródło
Ludzie sugerują dodanie
.
doPATH
, 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ędo twojego
~/.bashrc
pliku. 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żeszcd /etc
i piszfoo
, 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ływanefoo
jednocześnie~/dev/myprog1
i~/dev/myprog2
nie 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:
Czy można nazwać aliasy
.gizmo
i.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 twojegoPATH
. Jeśli złośliwy użytkownik może odczytać.bashrc
i zobaczyć swoje aliasy, to może on umieścić złośliwego oprogramowania o nazwiegizmo
orazgonzo
w przypadkowych katalogów, w nadziei, że będzie go uruchomić. Lepiej, aby używały bezwzględnych nazw ścieżek: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ę.źródło
make gizmo
lubmake gonzo
.Makefile
w każdym katalogu, tak aby akcjemake gizmo
zakończyły się uruchomieniemgizmo
? (1) Wydaje się to niezręcznym sposobem robienia tego samego, cop
funkcja zaproponowana w pytaniu, początkowo zaimplementowana przez aitap i udoskonalona przez Scotta. (2) Czy możesz przekazać argumenty w ten sposób? ISTM, którymake gizmo arg1 arg2
jest równoważnymake gizmo; make arg1; make arg2
../
w każdym katalogu . Moim zdaniem coś rozwija i po prostu musi./file
często uruchamiać wyprodukowany program . Naprawdę nie mogę myśleć o jakiejkolwiek innej sytuacji, w której można by często należy uruchomić plik lokalny, a jeśli nie jest uruchomiony to często nie chcesz pytać pytanie (powiedział, trudno nie niemożliwe ), (2) nie do końca , ale możesz przekazać argumenty z przepisu.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:(także, chyba że dowiązujesz symbolicznie
ld.so
do swojej ścieżki, nadal będziesz musiał napisać/
s)źródło
binfmt_misc
jest./libexec/ld-elf.so.1
. W systemie Linux nie jest to tak proste, jak „decyzja o uruchomieniu pliku binarnego”:binfmt_misc
wykrywa format pliku za pomocą magicznych liczb (ELF, skrypt shebang, CIL). Następniebinfmt_elf
wywoływany jest moduł obsługi. Analizuje nagłówki i sekcje ELF;.interp
sekcja zawiera ścieżkę dynamicznego modułu ładującego; ten moduł ładujący jest uruchamiany przez jądro, dokonuje relokacji i przeskakuje do_start
. Na FreeBSD (nie jestem pewien co do innych) nie ma binfmt, ale zasada jest podobna do +/-.ld.so
nie ma.interp
i jest statycznie powiązane, co oznacza, że nie potrzebuje innego dynamicznego linkera / modułu ładującego, aby rozwiązać swoje zewnętrzne symbole i wykonać matematykę relokacji.Jeśli wolno nam zacząć konfigurować
Większość współczesnych dystrybucji zawiera już ~ / .local / bin w $ PATH (dodaj
export PATH="$HOME/.local/bin:$PATH"
do twojego,~/.profile
jeśli twój nie). Następnie możesz użyćx file
do uruchomienia./file
.Nie próbuj definiować
.
polecenia. Polecenie. script
działa jużscript
w bieżącej powłoce. Pozwalascript
to zdefiniować zmienne środowiskowe dla bieżącej powłoki.źródło
exec "$@"
.$ (ln -s /bin/ls my-ls && exec my-ls) # bash: exec: my-ls: not found
shift $1
; właśnieexec ./"$@"
. (2) Ponieważ mówisz o skrypcie powłoki, jest trochę bezcelowe / wprowadzające w błąd doradzanie ludziom, aby nie definiowali.
polecenia, ponieważ niemożliwe jest utworzenie pliku o nazwie.
. (Możliwe i bardzo niewskazane jest zdefiniowanie aliasu lub funkcji powłoki o nazwie.
.)Jeśli wolno nam tworzyć skrypty pomocnicze, możesz zrobić pomocnika, który doda PWD do ŚCIEŻKI, a następnie uruchom
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
pushd
edytował ś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.Ale myślę, że jeśli chce biegać z nim można siekać
pushd
ipopd
tak mogą zrobić te same modyfikacje ścieżki bez bez podpowłoce które stracą inne zmiany.(Nie możesz zrobić tego samego,
cd
ponieważ nie ma analogu dopopd
.)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.
źródło
cd
, ale jest to jeszcze dalej: Utwórz plik podobny do.dircmds
i zhakuj,cd
aby polecenia zdefiniowane były./.dircmds
niedostępne tuż przed przełączeniem i dostępne zaraz po przełączeniu.Możesz używać
. script.sh
skł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
źródło
. script.sh
zepsuje się, jeśli skrypt zawieraexit
, ma nieoczekiwane efekty, np. jeśli przedefiniował PATH „tymczasowo”; działa również tylko w przypadku skryptów dla bieżącej powłokiexit
to, że możesz umieścić go w nawiasach, tj. podpowłokę, ale to prawda, nadal byłoby to tylko dla skryptów w tej samej powłoce.