Programmaufrufe unter Linux - warum mit ./

weil sie in einem höher angeordneten Verzeichnis liegen?

STK500-Besitzer schrieb:
> weil sie in einem höher angeordneten Verzeichnis liegen?
eher, weil sie im selben Verzeichnis liegen.

Wenn nur der Programmname angegeben wird, wird in den in PATH
angegebenen Pfaden danach gesucht.
Die andere Möglichkeit ist, den Pfad explizit anzugeben,
dabei ist . das aktuelle Verzeichnis.

../Programm würde beispielsweise etwas im übergeordneten Verzeichnis
aufrufen.
/bin/Programm absolut vom Wurzelverzeichnis aus usw...

Weil . aus Sicherheitsgründen zuweilen nicht im PATH ist.

genuer: bei linux wird nur der pfad ($PATH) nach dem programmnamen 
durchsucht.
wenn dein programm irgendwo in deinem home-verzeichnis liegt wird es, 
selbst wenn du im CLI im selben verzeichnis stehst nicht gefunden wenn 
du nicht den vollen (oder relativen) pfad angibst.

Udo Schmitt schrieb:
> Fred schrieb:
>> aus Sicherheitsgründen
>
> Warum aus Sicherheitsgründen?
> Die Frage ist ernst gemeint.

weil man so verhindert einem nutzer z.b. ein falsches "ls" 
unterzujubeln.
laut $PATH wird bei "ls -la" zuerst bin durchsucht, und nicht das 
verzeichnis in dem du grade stehst, z.b. ~/ .

Udo Schmitt schrieb:
> Warum aus Sicherheitsgründen?

Weil ich dir ein Programm mit dem Namen eines bash-builtins oder eines 
beliebigen anderen Programms, das du üblicherweise so aufrufst, in eins 
deiner Verzeichnisse (vermutlich ~) legen kann.

Und wenn du dann versuchst, das "eigentlich gemeinte" Programm 
aufzurufen, führst du meins aus. Mit deinen Rechten!

Jörg Wunsch schrieb:
> Fred schrieb:
>> Weil ich dir ein Programm mit dem Namen eines bash-builtins oder eines
>> beliebigen anderen Programms, das du üblicherweise so aufrufst, in eins
>> deiner Verzeichnisse (vermutlich ~) legen kann.
>
> In eins seiner Verzeichnisse kommt man als Fremder normalerweise
> nicht rein.

Da reicht's ja schon aus, wenn ich dir ein tar.gz schicke, du das bei 
dir entpackst und danach in dem Verzeichnis ein ls machst.

> Indem man sich angewöhnt, "." niemals in den PATH aufzunehmen, sondern
> stets ./ zu schreiben, wenn man etwas bewusst aus dem aktuellen
> Verzeichnis ausführen möchte, umgeht man dieses Risiko.

Es gilt halt unter Linux auch nicht als der Regelfall, daß man ein 
Programm im aktuellen Verzeichnis aufruft. Wenn ich mir z.B. ein 
Programm selbst compiliere und es dann vor der Installation schon im 
Build-Verzeichnis testhalber starten will, ist das eben sein 
Spezialfall.

Yalu X. schrieb:
> Man kann "." schon in die PATH-Variable mit aufnehmen, sollte aber
> darauf achten, dass es an letzter Stelle (oder zumindest nach allen
> Systemverzeichnissen) steht.


Wie soll das funktionieren, ohne in kürzester Zeit auf seltsame 
Ereignisse aufgrund gleichnamiger Dateien zu stoßen?
Z.B. Skripte ala configure.sh finden sich mehrere Dutzend.


Macht doch schon daher keiner, es wurde wohl ein Beispiel gebraucht ...

Das ist eine Eigenart von Linux, welches wirklich nur die, in der 
Path-Variablen, stehenden Verzeichnisse nach einem Befehl durchsucht. 
Interessanterweise schaut es auch nicht im aktuellen Verzeichnis nach.

Genau wie bei DOS ist das "Punkt"-Verzeichnis das aktuelle. Der einzige 
Unterschied ist die Linuxer stehen auf den Schrägstrich (/) und in der 
Dose ist ein Backslash (\). Also im übertragenen Sinne haben "./" und 
".\" die gleiche Bedeutung.

Yalu X. schrieb:
> Man kann "." schon in die PATH-Variable mit aufnehmen, sollte aber
> darauf achten, dass es an letzter Stelle (oder zumindest nach allen
> Systemverzeichnissen) steht.

Dann startet man allerdings versehentlich das falsche Programm, wenn es 
irgendwo im PATH schon eins mit dem gleichen Namen gibt. Der Klassiker 
ist da die Verwirrung, wenn jemand sich z.B. ein kleines C-Programm 
bastelt und es erstmal test nennt und sich dann wundert, warum sein 
printf ignoriert wird.

Jörg Wunsch schrieb:

> Allerdings (normalerweise) nicht innerhalb von PATH.

War eh ein bloedes Beispiel.



... und oups, was man nicht so alles in seiner /etc/profile findet,


if [ ! "`id -u`" = "0" ]; then
 PATH="$PATH:."
fi

"Nicht-Roots" bekommen beim Shell-Aufruf, hier bash (/etc/profile -> 
~/.bashrc), das aktuelle Verzeichnis in den Pfad gehaengt.

Aber ist das notwendig?

> ist, der potentiell Verwirrt-Werdende aber vergisst, dem "test" das "./"
> voranzustellen.
>
> Bei "test" passiert meist zum Glück nicht Schlimmes. Und dass man seine
> eigenen Programme nicht "rm" o.ä. nennt, das lehrt die Erfahrung ;-)

So jetzt allen nochmal ein herzliches RTFM ;)

man bash

.  filename [arguments]
       source filename [arguments]


Read and execute commands from filename  in  the  current  shell
environment  and return the exit status of the last command exe-
cuted from filename.  If filename does not contain a slash, filenames in
PATH  are used to find the directory containing filname.  The file
searched for in PATH  need  not  be executable.
When  bash  is  not  in  posix  mode,  the  current directory is 
searched
if no file is found in PATH.  If the sourcepath option to  the  shopt
builtin  command  is turned off, the PATH is not searched.  If any
arguments are supplied, they become the positional  parameters  when
filename  is  executed.  Otherwise the positional parameters are
unchanged. The return status  is the status  of  the  last  command 
exited
within the script (0 if no commands are executed), , and false if 
filename
is  not  found  or cannot be read.


This builtin is equivalent to source.

19:25 schrieb:
>> ist, der potentiell Verwirrt-Werdende aber vergisst, ...

Toller Satz,


> So jetzt allen nochmal ein herzliches RTFM ;)

shortcut, for full viewer convenience

$ man bash|less -p '.  filename \[arguments\]'

Mit etwas gutem willen kriegst du das bestimmt noch unfreundlicher hin.

Nein ist nicht das selbe, aber nicht alles was ausgefuehrt werden kann
muss auch nicht unbedingt als ausfuehrbar gekennzeichnet sein.


$ mkdir spielwiese
$ cd spielwiese

$ echo 'echo "Hello World!"' > hello

$ ls -n
total 4
-rw-r--r-- 1 1001 1001 20 2014-02-26 11:50 hello

$ ./hello
bash: ./hello: Permission denied
$ hello
bash: hello: command not found
$ . hello
Hello World!


----------------

$ chmod u+x hello
$ ./hello
Hello World!
$ hello
bash: hello: command not found
$ pwd
/tmp/spielwiese
$ PATH="$PATH:/tmp/spielwiese"
$ hello
Hello World!

11:55 schrieb:
> Mit etwas gutem willen kriegst du das bestimmt noch unfreundlicher hin.

Da muß man sich ja nicht wundern, wenn man großkotzig mit "RTFM" 
auftritt und dann das Thema verfehlt.

> Nein ist nicht das selbe

Ist was vollkommen anderes...
Beim ./ geht's darum, explizit das Verzeichnis anzugeben, wo das 
Programm liegt, das ausgeführt werden soll. Das einfache . ist das 
gleiche wie das Kommando 'source' und dient dazu, ein Skript statt in 
einer neuen Shell-Instanz in der aktuellen auszuführen.

11:55 schrieb:
> $ . hello
> Hello World!

Das geht aber auch nur bei Skripten.

Ach Leute,

ich verirre mich ja wirklich selten in diese Gefilde hier - aber eure 
Diskussion hat mir mal wieder drastisch vor Augen geführt, warum ich 
Linux und alle unixoide BS nicht leiden mag. Mit größerem Abstand 
gesehen ist es wohl doch ein General-Bug, unixoide Shells überhaupt in 
einem Rechnersystem zu haben. Jetzt verweist bitte nicht auf abgesetzte 
Systeme und deren Fernwartung, ein PC ist nicht sowas und abgesetzte 
systeme sollten eine Firmware intus haben. FIRM eben.


Manchmal kommt mir so ein abenteuerlicher Traum, bei derartigen OS 
einfach sämtliche Shells ersatzlos zu entfernen, dazu gleich auch noch 
sämtliche Shell-Skripte. Als nächstes auch noch führende Punkte bei 
Dateinamen verbieten und für ausführbare Dateien zwingend eine 
entsprechende Extension vorzuschreiben, die Ausführung von Dateien auf 
das aktuelle Verzeichnis zu beschränken mit Ausnahme von Anwendungen, 
die vom BS als namentlich bekannte und system-modale Anwendungen 
dediziert geführt werden oder per qualifizierter Pfadangabe. Als 
nächstes dann ersatzloses Entfallen jeglicher "home" Verzeichnisse und 
deren Ersatz durch Installationsverzeichnisse der Anwendungen innerhalb 
der Volumes sowie Einführen eines generellen Verzeichnisses "linux", wo 
ALLES, was sich bisher sonstwo im root Verzeichnis tummelt, 
hinverschoben ist, nur Verzeichnisse aber keinerlei Datei in root 
möglich, kurzum freiräumen von root, bis es etwa so aussieht wie bei 
Windows CE: nix außer temp, windows und benannte Volumes (soviel wie 
physisch vorhanden).

... ok, für begeisterte Linuxer dürfte das eher ein Alptraum sein, 
zwingt es sie doch zu einem Arbeiten mit Applikationen anstelle von 
Tools ;-)

n schönen Abend noch,

W.S.

W.S. schrieb:
> ich verirre mich ja wirklich selten in diese Gefilde hier - aber eure
> Diskussion hat mir mal wieder drastisch vor Augen geführt, warum ich
> Linux und alle unixoide BS nicht leiden mag. Mit größerem Abstand
> gesehen ist es wohl doch ein General-Bug, unixoide Shells überhaupt in
> einem Rechnersystem zu haben.
Sowas kann nur jemand sagen, der nicht im geringsten weiß wovon er da 
redet.