gcc cc unsw

Hallo

Ich möchte gerne Programmieren lernen nun habe ich ein
kleines Beispiel von meinem Buch.
Wenn ich das Programm aber Compiliere so funktioniert
das, aber das Programm kann ich nicht ausführen.
Es kommt auch keine Fehlermeldung da ja das Compilieren
funktioniert hat. Was ist da falsch ?

cc -o test test.c

Bemerkung :

Mein Programm test.c

#include <stdio.h>

main(void)
{
printf("Hallo");
}

Was ist der Unterschied von gcc ? Und wie funktioniert es mit einem
make File ?

Gibt es irgendwo eine genaue anleitung für die make Files ?
Bitte einen Link Danke

Danke für Eure Hilfe

rüdiger

Unter Linux ist die GCC idr. der cc. Wie führst du dein Programm denn aus? Ändert sich etwas, wenn du ein \n an das Hello anfügst?

mit /n ändert sich nichts !

Ich rufe einfach den Namen auf test und danach die Enter Taste.

Gruss

Harry

Bashar

Boss_Harald schrieb:

mit /n ändert sich nichts !

Das war zu erwarten. Du solltest es ja auch mit \n versuchen.

Ich rufe einfach den Namen auf test und danach die Enter Taste.

Und was passiert dann? Fehlermeldung? Absturz? Keine Ausgabe?

rüdiger

lol

probier es mal mit ./test - du rufst vermutlich ein anderes Programm auf, das test heißt (wird für die Shell-Programmierung benötigt)

<mit /n ändert sich nichts !
<Das war zu erwarten. Du solltest es ja auch mit \n versuchen.

Sorry hatte ich natührlich ist nur ein Schreibfehler

Zitat:
Ich rufe einfach den Namen auf test und danach die Enter Taste.
Und was passiert dann? Fehlermeldung? Absturz? Keine Ausgabe?

Es passiert nichts hatte ich schon oben erwähnt !
keine Fehlermeldung
keinen Absturz
keine Ausgabe

./test Danke das funktioniert !

Ein anderes Programm ? Übrigens ich habe das Linux das 1 mal
installiert und hatte vorher nur mit Win2000 gearbeitet.

Da man ja im Win2000 ebenfals nur den Namen aufruft hatte ich das
selbe gemacht da ja nur ein Programm test in diesem Verzeichnis
existiert.

Warum ist das ./ hier nötig ? Ist den der Pfad von meinem Arbeitsverzeichnis
nicht definiert ?

Ich nehme mal an das dies ./ zu bedeuten hat das, das Programm test von diesem
aktuellen Verzeichnis ausgeführt werden soll.

Aber warum das ganze weil ich bin ja schon in diesem Verzeichnis ?

ps: Wahrscheindlich bin ich von Microsoft geprägt

Gruss

Harry

Wo kann man den Pfad definieren ? (ich habe Suse10 installliert )

rüdiger

Aus Sicherheitsgründen geht die Shell eben erst die "offiziellen" Pfade durch (/bin /sbin /usr/bin /usr/sbin /usr/local/bin usw.). Wenn nämlich jemand schafft ein gefälschtes Programm (zB ssh) in dein Verzeichnis zu legen, könnte er zB Passwörter erfahren oder Befehle mit deinen Rechten ausführen. Daher ist das schon ganz praktisch wie es ist. Bei den meisten Distributionen wird . (eben der aktuelle Pfad) gar nicht nach Ausführbarendateien durchsucht. Daher ist es eigentlich üblich in dem Fall ./ vorzuschreiben.

Wenn du es wirklich ändern willst, dann solltest du die PATH-Umgebungsvariable ändern. Aber wie gesagt, ich kann dir nur davon abraten und wo ist das Problem ./ zu benutzen? (Unter SuSE sollte es sogar reichen, ein Programmnamen zu wählen, der nicht bereits existiert, da bei SuSE . afair in PATH enthalten ist.)

supertux

rüdiger schrieb:

Aus Sicherheitsgründen geht die Shell eben erst die "offiziellen" Pfade durch (/bin /sbin /usr/bin /usr/sbin /usr/local/bin usw.).

Nop, das ist falsch. Wenn man keinen absoluten Pfad eingibt, vervollständigt die Shell den Pfad der auszuführenden Datei mit den Verzeichnissen aus der PATH Variable. Die PATH Variable wird meistens mit /usr/local/bin:/usr/bin:/bin oder ähnliches initialisiert, muss aber nicht der Fall sein.

rüdiger schrieb:

Wenn nämlich jemand schafft ein gefälschtes Programm (zB ssh) in dein Verzeichnis zu legen, könnte er zB Passwörter erfahren oder Befehle mit deinen Rechten ausführen.

das Problem hat man aber überall, selbst bei Windows, das hat aber nichts damit zu tun, dass man Programme ohne ./ ausführen kann, denn wichtig ist, welche Pfade von PATH zuerst durchsucht werden. Beim obigen Beispiel kann der Eingreifer die "böse" ssh in /usr/local/bin anlegen und wenn ich ssh ausführe, dann wird die "böse" ausgeführt.

@Harald:

Führe echo $PATH aus, und du wirst die Liste der Verzeichnisse bekommen, die durchsucht werden. Dein Working Directory wird mit sehr höher Wahrscheinlichkeit nicht aufgelistet sein, deswegen wird test nicht ausgeführt. Deswegen musst du den Pfad angeben. Du kannst auch (angenommen dein Working Dir ist /home/user/irgendwas) mit /home/user/irgendwas/test das Programm starten, oder ./test, wobei das ./ in /home/user/irgendwas/ von der Shell "verwandelt" wird. Bei Windows funktioniert genau so mit dem Unterschied, dass Windows auch innerhalb des Working Directories sucht, obwohl er nicht in der PATH Variable aufgelistet ist.

nman

supertux schrieb:

rüdiger schrieb:

Aus Sicherheitsgründen geht die Shell eben erst die "offiziellen" Pfade durch (/bin /sbin /usr/bin /usr/sbin /usr/local/bin usw.).

Nop, das ist falsch.

Nein, ist es nicht. Was soll daran denn falsch sein?

Beim obigen Beispiel kann der Eingreifer die "böse" ssh in /usr/local/bin anlegen und wenn ich ssh ausführe, dann wird die "böse" ausgeführt.

Nein, kann er nicht, denn /usr/local/bin ist nur für Root beschreibbar, der Angreifer braucht also bereits Root-Rechte, um da reinschreiben zu können, was nicht wahnsinnig sinnvoll wäre.

ronny

@nman:

supertux hat recht - es gibt kein aus sicherheitsgründen zuerst die std pfade

die shell testet einfach alles was in $PATH ist durch - und zwar der reihenfolge nach

für gewöhnlich haben die distributionen jedoch sicherheitstechnisch praktische defaults für $PATH und als user sollte man neues hinten dran hängen

nman

r0nny schrieb:

die shell testet einfach alles was in $PATH ist durch - und zwar der reihenfolge nach

Natürlich. Und da sind (aus Sicherheitsgründen) eben zunächst mal die diversen Standard-Pfade drin. Auf $PATH hat rüdiger ja ohnedies hingewiesen, weiß also nicht, was der Post von supertux an neuen Informationen beinhalten hätte sollen.

supertux

Ich glaube, wie reden alle aneinander vorbei.

Ich meinte mit "falsch", dass die SHELL nicht standardmäßig sofort in /bin/, /usr/bin usw. die Programme sucht, unabhängig vom Inhalt von $PATH (so verstehe ich das aus Rüdigers Beitrag), sondern sich nur auf $PATH beschränkt. Dass PATH in der Regel als erstes /bin, /usr/bin, usw. hat, ist meiner Meinung nach eine andere Sache, es kann sein, dass diese Konstellation so as Sicherheitsgründen enstanden ist, das weiß ich aber nicht, mir ging es nur, dass die SHELL sich auf $PATH beschränkt. Aber jeder kann die PATH Variable ändern und dann ändert sich das Verhalten der SHELL.

supertux@supertux:~> PATH=
supertux@supertux:~> ls
bash: ls: No such file or directory

Nein, kann er nicht, denn /usr/local/bin ist nur für Root beschreibbar, der Angreifer braucht also bereits Root-Rechte, um da reinschreiben zu können, was nicht wahnsinnig sinnvoll wäre.

Das gleiche Argument kann ich für das Working Directory benutzen, der Angreifer braucht die Rechte des Benutzers. Rüdiger schriebt ja "Wenn nämlich jemand schafft ein gefälschtes Programm".

nman

supertux schrieb:

Ich meinte mit "falsch", dass die SHELL nicht standardmäßig sofort in /bin/, /usr/bin usw. die Programme sucht, unabhängig vom Inhalt von $PATH (so verstehe ich das aus Rüdigers Beitrag), sondern sich nur auf $PATH beschränkt.

Das wissen sowohl rüdiger als auch ich. Und rüdiger hat in seinem Post auch auf $PATH hingewiesen.

Das gleiche Argument kann ich für das Working Directory benutzen, der Angreifer braucht die Rechte des Benutzers. Rüdiger schriebt ja "Wenn nämlich jemand schafft ein gefälschtes Programm".

Nein, das WD muss ja nicht das Homedirectory sein. Kann durchaus auch /pub oder /tmp oä sein; irgendein Ort eben, wo auch Non-Root-User hineinschreiben dürfen.

supertux

nman schrieb:

Nein, das WD muss ja nicht das Homedirectory sein. Kann durchaus auch /pub oder /tmp oä sein; irgendein Ort eben, wo auch Non-Root-User hineinschreiben dürfen.

deswegen hab ich ja WD und nicht HOME geschrieben. Aber streiten wir nicht weiter wegen einer Ungenauigkeit, wobei wir alle dasselbe meinen

Marcin

Unter SuSE sollte es sogar reichen, ein Programmnamen zu wählen, der nicht bereits existiert, da bei SuSE . afair in PATH enthalten ist

Das muss aber eine ziemlich alte version von Suse sein.
So weit ich mich erinnere war seid Version 8.0 ./ standardmeßig nicht in PATH enthalten.

LordJaxom

Marcin schrieb:

Das muss aber eine ziemlich alte version von Suse sein.
So weit ich mich erinnere war seid Version 8.0 ./ standardmeßig nicht in PATH enthalten.

Zumindest bei dem 8.3 hier ist . am Ende von $PATH bei allen Usern. Bei root natürlich nicht. Und IMHO ist das bei aktuellen SuSEs und einigen anderen Distributionen genauso.

Marcin

Und IMHO ist das bei aktuellen SuSEs
Falls du 10.2 meinst, dann vielleicht , diese Version habe ich noch nicht benutzt. In Version 10.1, 10.0 ist es auf jeden Fall nicht so, 8.0 und 8.2 hatte ich auch einige Zeit benutzt, da war es auch nicht so.
Es ist mir jedenfalls noch bei keiner Suse Version (auch bei 9er) aufgefallen dass PATH auch ./ beinhalten würde. Ausgerechnet 8.3 hatte ich nicht mal installiert gehabt.

rüdiger

supertux schrieb:

Ich meinte mit "falsch", dass die SHELL nicht standardmäßig sofort in /bin/, /usr/bin usw. die Programme sucht, unabhängig vom Inhalt von $PATH (so verstehe ich das aus Rüdigers Beitrag), sondern sich nur auf $PATH beschränkt.

Ich wollte mir bei der Erklärung kein Bein ausreissen. Ansonsten siehe nmans Beiträge.