Führen Sie als .test statt ./test aus

Angenommen, ich befinde mich im selben Ordner wie eine ausführbare Datei, dann müsste ich Folgendes eingeben, um sie auszuführen:

./file

Ich würde lieber nicht tippen müssen /, weil /es für mich schwierig ist zu tippen.

Gibt es eine einfachere Möglichkeit, eine Datei auszuführen? Idealerweise nur eine einfache Syntax wie:

.file

oder etwas anderes, aber einfacher, als das /Zeichen dort einfügen zu müssen.

Vielleicht gibt es eine Möglichkeit, etwas in das /binVerzeichnis einzufügen oder einen Alias ​​für den Interpreter zu erstellen, damit ich Folgendes verwenden kann:

p file

Es kann "riskant" sein, aber Sie könnten nur haben. in deinem PFAD.

Wie in anderen gesagt wurde, kann dies gefährlich sein, stellen Sie also immer sicher. ist am Ende des PFADS und nicht am Anfang.

.wird sich automatisch vervollständigen./ (tippen .und drücken Tab), zumindest in modernen Bash-Shells, sodass Sie keine komplexe oder unsichere PATHLösung (wie das Ändern) verwenden müssen.

Wenn es nicht automatisch vervollständigt wird, müssen Sie möglicherweise das Paket "bash-completion" installieren.

oder .. vielleicht dem Interpreter einen Alias ​​in der bashrc-Datei geben und dann einfach

   p  file

Es ist möglich, eine solche Funktion zu schreiben:

p() {
 ./"$@"
}

in deinem ~/.bashrc. Dann können Sie p app argumentsstattdessen laufen ./app arguments. Diese Lösung funktioniert für ausführbare Dateien aller Art, einschließlich Skripts und Binärdateien.

"$@"dehnt sich in geeigneter Weise zitierte Liste der Argumente an die Funktion übergeben (alle Sonderzeichen aus glob oder variable Expansion zu bewahren), und als @ Scott wies darauf hin, bashklug genug , um prepend ist ./auf der ersten von ihnen, den Rest zu erhalten.

Sie können dies tun ., $PATHindem Sie z. B. PATH=$PATH:.zu Ihrem hinzufügen /etc/profile. Auf diese Weise können Sie es filenur durch Schreiben ausführen file, es sei denn, es befindet sich in einem anderen Ordner in Ihrem Pfad (z /usr/bin/. B. ). Beachten Sie, dass dies im Allgemeinen keine gute Idee ist.

Warum es so schlimm ist: Angenommen, Sie befinden sich in einer Situation, in der Sie dem Inhalt eines Verzeichnisses nicht vollständig vertrauen - Sie haben es von einem zweifelhaften Ort heruntergeladen und möchten es untersuchen, bevor Sie es ausführen, oder Sie sind ein Sysadmin, der einigen hilft Sie möchten das Verzeichnis auflisten, also versuchen Sie, ls einzugeben, aber hoppla, Sie machen einen Tippfehler und geben stattdessen sl ein. Der Autor dieses schädlichen Verzeichnisses hat dies vorausgesehen und ein Shell-Skript namens "sl" eingefügt, in dem "rm -rf --no-preserve-root /" (oder etwas Bösartigeres wie die Installation eines Rootkits) ausgeführt wird.

(Danke @Muzer für die Erklärung)

Sie können beispielsweise den Dolmetscher anrufen

bash test

In diesem Fall wird das Skript auch dann ausgeführt, wenn es weder eine Shebang-Zeile (z. B. #!/bin/bash) noch ein ausführbares Bit enthält. Sie müssen den richtigen Interpreter kennen, um es auch ausführen zu können. Sie können die shebang-Zeile der Datei zuerst lesen, um sicherzustellen, dass Sie den richtigen Interpreter aufrufen, zum Beispiel, wenn die shebang-Zeile lautet

#!/usr/bin/env python3

du würdest anrufen

python3 test

Soweit ich weiß, gibt es keine Möglichkeit, dies zu erreichen, es sei denn, Sie fügen die Datei in den ENV-Pfad ein, und Sie könnten es einfach ausführen, indem Sie Folgendes eingeben: file

.filefunktioniert nicht, da dies ein anderer Dateiname ist. Es ist eine Datei namens .fileund nicht ./file.

Ich habe das Gefühl, dass es schwierig sein kann, Schrägstriche für Sie zu schreiben, weil das Layout nicht englisch ist, vielleicht? In diesem Fall passiert es mir auch, also tausche ich mein Tastaturlayout häufig durch Drücken von Alt + Shift in Windows in Englisch aus (ich verwende Linux von ssh aus).

Die Leute haben vorgeschlagen , das Hinzufügen .zu PATH, was gefährlich ist , weil es ein Risiko darstellt, dass Sie versehentlich ein bösartiges Programm gepflanzt in einer Welt beschreibbaren Verzeichnis ausgeführt werden. Aber, wenn Sie in ein paar Verzeichnisse ausführbare Programme, die Sie besitzen und beschreibbar sind nur von Ihnen, dann ist es sicher (ziemlich sicher?) Stellen diejenigen Direktor (en) in PATH, indem Sie eine Zeile wie

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

zu Ihrer ~/.bashrcDatei. Dies bedeutet natürlich, dass Sie ein Programm von einem dieser Verzeichnisse aus von einer beliebigen Stelle im Dateisystem ausführen können. Zum Beispiel könnten Sie cd /etcund eingeben foo, und es würde laufen ~/dev/myprog1/foo. Dies hat den kleinen Nachteil, dass Sie nicht in mehr als einem der Verzeichnisse gleichnamige Programme haben können. Insbesondere wenn Sie Programme haben, die foo in beiden ~/dev/myprog1und aufgerufen werden ~/dev/myprog2, können Sie das zweite Programm nur ausführen, indem Sie einen Pfad angeben. Ebenso, wenn Sie eine haben ~/dev/myprog1/cat- aber warum würden Sie wollen?

Ein anderer Ansatz, wenn Sie nur wenige Programme haben, mit denen Sie dies tun, besteht darin, Aliase für diese zu definieren:

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

Oder Sie können die Aliase anrufen .gizmound .gonzo wenn Sie das intuitiver finden.

Dies birgt .in gewissem Maße das gleiche Sicherheitsrisiko, das Sie auch in Ihrem Computer haben PATH. Wenn ein böswilliger Benutzer Ihre lesen kann .bashrcund Ihre Aliase sieht, dann könnte er Malware genannt gesetzt gizmound gonzoin zufälligen Verzeichnissen , in der Hoffnung , dass Sie es laufen werden. Es ist besser, dafür absolute Pfadnamen zu verwenden:

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

Übrigens sollten Sie die Benennung einer ausführbaren Datei vermeiden test, da dies ein in die Shell integrierter Befehl ist, und Sie können ein Programm mit diesem Namen nur ausführen, indem Sie einen Pfad oder einen anderen Trick angeben.

Um die Antwort von Zanna zu Interpreten zu erweitern (Entschuldigung, kein Mitarbeiter für einen Kommentar): Ein "Interpreter" für native ausführbare Dateien (auch als binäre ELF-Dateien bezeichnet) ist der dynamische Loader ( ld.so), versteht jedoch in der Regel nicht die gewünschte Syntax:

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

(Auch wenn Sie nicht ld.soauf Ihren Pfad verlinken , müssen Sie noch /s schreiben. )

Wenn wir anfangen dürfen, Dinge zu konfigurieren

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

In den meisten modernen Distributionen ist ~ / .local / bin bereits in $ PATH enthalten (fügen Sie dies export PATH="$HOME/.local/bin:$PATH"zu Ihren hinzu , ~/.profilewenn dies bei Ihnen nicht der Fall ist). Dann kannst du x filemit rennen ./file.

Versuchen Sie nicht, einen .Befehl zu definieren . Der Befehl wird . scriptbereits scriptin der aktuellen Shell ausgeführt. Dadurch können scriptUmgebungsvariablen für die aktuelle Shell definiert werden.

Wenn wir Hilfsskripte erstellen dürfen, können Sie einen Helfer erstellen, der das pwd zum PATH hinzufügt, und dann ausführen

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

Dies vermeidet das Hinzufügen von "." auf den Pfad und verschmutzen Sie Ihr .profile mit jedem Pfad, in dem Sie irgendwann etwas ausführen möchten.

Wir können diesen Ansatz noch einen Schritt weiter gehen, indem wir einen Helfer erstellen, der eine neue Shell mit einem modifizierten PATH startet. Wenn ein Verzeichnis als Parameter verwendet wird (standardmäßig wird pwd verwendet), funktioniert es wie ein pushd, das den Pfad bearbeitet. Möglicherweise müssen Sie sich bewusst sein, dass Änderungen an anderen Umgebungsvariablen beim Verlassen der Subshell verloren gehen, aber in einer lang laufenden Shell wird Ihre PATH-Variable nicht überfüllt sein. Abhängig von Ihren Arbeitsabläufen kann dies vorteilhaft sein.

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

Aber ich denke, wenn Sie damit laufen wollten, könnten Sie hacken pushdund popdso können sie die gleichen Änderungen am Pfad vornehmen, ohne eine Subshell zu erstellen, die andere Änderungen verliert.

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

(Mit kann man nicht dasselbe machen, cdda es kein Analogon zu hat popd.)

Sie können auch ein spezielles Hilfspaar erstellen, um PATH-Einträge zu verschieben und zu platzieren. Was am besten funktioniert, hängt wirklich von Ihren Nutzungsmustern ab.

Sie können die . script.shSyntax verwenden, solange sich das Skript, das Sie ausführen möchten, im aktuellen Verzeichnis befindet.

Sie können dem Interpreter auch ein Präfix voranstellen, z. B. sh oder bash. Beispiel:bash script.sh