./ weglassen?

[bullitt168]

Hallo! Ich bin gerade dabei, mir ein wenig c++ anzueignen, verwende vim als editor und den gcc als compiler, arbeite also direkt auf der konsole. Was mich nur ein wenig nervt ist, daß ich die compilate immer mit ./compilat starten muss und nicht einfach "compilat" eingeben kann.
Wenn ich das richtig verstanden hab, ist das problem, daß die shell (bash in meinem fall) nicht im aktuellen Pfad nach der ausführbaren datei sucht... Meine Frage also: Wie kann ich z.B. in der .bash_profile mit Hilfe der PATH-Variable den jeweils aktuellen Pfad hinzufügen?


Wäre für hilfe Dankbar,


Bastian!

 

[-Nuke-]

Na ganz einfach ./ in deine PATH eintragen.

Z.B.

export PATH=$PATH:./

in die bash_profile eintragen. Hab es zwar jetzt nicht getestet, sollte aber funktionieren.

 

[crashx]

das wäre eine ganz krasse sicherheitslücke!
stell dir vor ein user auf deinem system erstellt ein programm was eine shell kopiert und dann suid setzt, dieses programm nennt er ls und packt es in eins seiner verzeichnisse. dann sagt er dir guck dir mal an was ich in dem verzeichnis xy hab. du tust es und er bekommt eine shell mit deinen rechten... also ich empfehle dir das nich zu tun, die zeichen kannste jawohl eintippen!

 

[klaus41542]

Na ganz einfach ./ in deine PATH eintragen.

Z.B.

export PATH=$PATH:./

in die bash_profile eintragen. Hab es zwar jetzt nicht getestet, sollte aber funktionieren.

nicht ./ sondern nur . in der PATH Anweisung.

ABER: siehe den vorherigen Beitrag. Nur Anwenden, wenn du mit Sicherheit allein auf deinem Mac arbeitest.

 

[maceis]

seh ich auch so, crashx.

Man könnte sich aber ein Verzeichnis ~/bin anlegen, in dem man nur selbst Schreibrecht hat.
Dahinein legt man seine eigenen Binaries.
Nun kann man "~/bin" problemlos in den Suchpfad aufnehmen:

export PATH=$PATH:~/bin

Am besten schreibt man das dann in die "~/.bash_profile" etc. und man hat Ruhe

 

[Agmemon]

Und wenn Du das ./ immer brav eingibst, hast Du auch einen Gewöhnungsfaktor.

Nette Geschichte dazu:
Ein Studienkollege hat sich die Pfadvariable auch angepaßt, damit er sich das ./ sparen konnte. Monate später hat er versucht ein Programm auf einer anderen Machine zu starten. Er hat ne Stunde nach dem fehler gesucht, bis er darauf kam, das ./ anzugeben.

 

[KAMiKAZOW]

das wäre eine ganz krasse sicherheitslücke!
stell dir vor ein user auf deinem system erstellt ein programm was eine shell kopiert und dann suid setzt, dieses programm nennt er ls und packt es in eins seiner verzeichnisse.

Ach was. Das wäre nur in dem Fall so, wenn "." am Anfang des Suchpfades stehen würde. Steht "." am Ende, wird erst /bin/ durchsucht und das System findet dort den richtigen ls-Befehl.
Wenn man ausdrücklich ./ls ausführen will, muss man das noch immer genau so eingeben.

MS-DOS hatte in seinen knapp 15 Jahren auch niemals Probeleme mit schädlichen dir.exe-Anwendungen, weil der System-Befehl "dir" höchste Priorität hatte.

 

[Sym]

Ach was. Das wäre nur in dem Fall so, wenn "." am Anfang des Suchpfades stehen würde. Steht "." am Ende, wird erst /bin/ durchsucht und das System findet dort den richtigen ls-Befehl.
Wenn man ausdrücklich ./ls ausführen will, muss man das noch immer genau so eingeben.

MS-DOS hatte in seinen knapp 15 Jahren auch niemals Probeleme mit schädlichen dir.exe-Anwendungen, weil der System-Befehl "dir" höchste Priorität hatte.

Also soweit ich das noch von Linux kenne, wird zunächst der Befehl im Verzeichnis ausgeführt - wenn der nicht existiert, wird gesucht.
Und MS-Dos und Linux/Unix ist eigentlich nicht vergleichbar.

 

[klaus41542]

Ach was. Das wäre nur in dem Fall so, wenn "." am Anfang des Suchpfades stehen würde. Steht "." am Ende, wird erst /bin/ durchsucht und das System findet dort den richtigen ls-Befehl.
Wenn man ausdrücklich ./ls ausführen will, muss man das noch immer genau so eingeben.

MS-DOS hatte in seinen knapp 15 Jahren auch niemals Probeleme mit schädlichen dir.exe-Anwendungen, weil der System-Befehl "dir" höchste Priorität hatte.

dir ist ein interner Befehl aus command.com und außerdem war es ein Beispiel und bestimmt nicht einzige Möglichkeit das System zu beeinträchtigen. Wir müssen ja nicht alle aufzählen. In der Unix community ist das Problem bekannt und wird so gehandhabt.

 

[KAMiKAZOW]

dir ist ein interner Befehl aus command.com

Ich weiß. Mir ging es ja auch nur darum welche Priorität das System einem Befehl gibt. Und durch die Reihenfolge der Pfadangabe kann man eben die Priorität selbst festlegen.

Also ich habe es eben ausprobiert. Ich habe ein Shell-Script "ls" erstellt. Dann habe ich "ls" eingegeben und das Script wurde nicht ausgeführt, weil "." am Ende der Pfadangabe steht und /bin/ zuerst durchsucht wurde.

Mein Fazit: Die Furcht über "." im Pfad ist Paranoia.