Prob. bei ausführen

[freak_out]

Hallo leute ich habe gerade mal einHallo Programm unter linux gemacht. um zu gucken ob es geht (ist das erste mal das ich unter linux proge)


Der Code ist

// hallo.cpp
#include <iostream>
using namespace std;

int main(void){
	cout << "Hallo linux";
	return 0;
}

So habe den code Kompiliert und erstellen lassen.

Wenn ich aber jetzt über Konsole das Programm starten will dann kommt folgendes:

freakout@freakout-desktop:~$ hallo               
bash: hallo: command not found
freakout@freakout-desktop:~$

Wieso startet das Programm nicht. Muss ich unter linux noch was am Quelltext ändern

Gruß freak_out

 

[Guest]

Weiß nicht genau ob man das muss, aber ist das programm ausführbar gemacht wordeN?

Und, befindest du dich auch im pfad wo sich "hallo" befindet?

wie hast du es kompiliert? mit gcc -o ?

Welche distri?

 

[freak_out]

Weiß nicht genau ob man das muss, aber ist das programm ausführbar gemacht wordeN?

Und, befindest du dich auch im pfad wo sich "hallo" befindet?

wie hast du es kompiliert? mit gcc -o ?

Welche distri?

Als Distri verwende ich Ubuntu. Als IDE verwende ich geany. Hab es mit den compiler und Link von Geany gemacht.

 

[gropiuskalle]

Und, befindest du dich auch im pfad wo sich "hallo" befindet?

Entweder das oder man packt das ganze in $PATH (wobei ein 'Hello World' da wohl wenig zu suchen hat).

 

[freak_out]

Also ich bin schon richtig. Bin im Verzeichnis wo auch "hallo" liegt.

EDIT:

Wenn ich jetzt im IDE auf Ausführen geh dann startet das porg. Aber ich kann es nicht via Konsole starten.

 

[doc]

chmod 755 hallo #ums ausführbar zu machen
./hallo #ums auszuführen

 

[rikola]

chmod 755 hallo #ums ausführbar zu machen
./hallo #ums auszuführen

Das wird wahrscheinlich eher nicht das Problem sein, da ein Kompiler i.d.R. doch die erzeugten Dateien schon als ausfuehrbar erstellt.

Das Problem wird das von tommek228 und gropiuskalle bereits angesprochene:
Meistens ist das aktuelle Pfad nicht in der PATH-Variable enthalten, d.h., Du musst das Programm mit ./hallo starten, damit die Shell weiss, dass es im aktuellen Verzeichnis nach der Datei suchen soll.

Gib doch zum Testen mal 'echo $PATH' ein. Dann sollte Du eine durch ':' getrennte Liste erhalten, in der '.' oder './' NICHT auftaucht. Die Verzeichnisse, die dort aufgelistet sind, sind genau die, in denen Dein Kommandozeileninterpreter nach den 'Worten', die Du als Befehle eingibst, sucht, um sie dann auszufuehren. Wenn '.' nicht in der Liste enthalten ist, so schaut der Interpreter dort auch nicht nach und findet das Programm nicht. Durch eine angefuegtes './' behebst Du dieses Problem (oder Du fuegst '.' mittels 'export PATH=$PATH:.' Deinem Pfad hinzu).

 

[Jabo]

Das mit dem "." im Pfad gilt aber auch als gefährlich (weshalb das System das eben normalerweise nicht macht)

Einige Systeme stellen einen 'workaround' bereit, indem im Suchpfad ein Punkt eingetragen wird ("."). Dies ermöglicht die Suche nach und das Ausführen von Dateien im aktuellen Pfad. Dies ist sehr gefährlich, da möglicherweise aus Versehen anstelle der normalen Systemdateien unbekannte Programme im aktuellen Verzeichnis gestartet werden. Diese Option erleichtert das Ausführen von 'Trojanischen Pferden', die diese Schwäche ausnutzen und Ihr System gefährden.

Man sollte sich also überlegen, ob man sich das für die Bequemlichkeit, bei manuellem Start auf "./" zu verzichten, einhandelt. Denn die Systembefehle, die ja in $PATH sind, gehen ohne Angabe eines solchen.

 

[supersucker]

@freak_out

To cut a long story short:

./hallo

Feddich.

 

[Jabo]

./hallo

hm... und was besprechen wir hier gerade?

 

[daboss]

Wie man hallo in $PATH bekommt?

 

[supersucker]

hm... und was besprechen wir hier gerade?

Ich wollte einfach der drohenden Verwirrung des TEs vorbeugen.

Und wieso man jetzt darüber diskutiert

/mein/toller/workspace/mein/kleines/Projekt/meine/bin/datei

in den Pfad aufzunehmen ist mir schleierhaft.

 

[doc]

Das mit dem "." im Pfad gilt aber auch als gefährlich (weshalb das System das eben normalerweise nicht macht)

ähhm hä? was soll daran gefährlich sein, wenn ich in der console

./MeinTollesProgramm

ausführe, solange ich da nich selber nen trojaner programmiert habe ?

Naja bei SuSe Kann ich mir einiges vorstellen, aber das nun auch wieder nich (ich glaube nich das sich der hilfetext auf die arbeit in der console bezieht -- lass mich aber gerne eines besseren belehren)

edit: hmmh beim näheren hinsehen bezieht es sich wohl doch auf die console, aber naja man muss halt wissen was man da ausführt, und das sollte man immer.

 

[daboss]

ähhm hä? was soll daran gefährlich sein, wenn ich in der console

./MeinTollesProgramm

ausführe, solange ich da nich selber nen trojaner programmiert habe ?

Naja bei SuSe Kann ich mir einiges vorstellen, aber das nun auch wieder nich (ich glaube nich das sich der hilfetext auf die arbeit in der console bezieht -- lass mich aber gerne eines besseren belehren)

edit: hmmh beim näheren hinsehen bezieht es sich wohl doch auf die console, aber naja man muss halt wissen was man da ausführt, und das sollte man immer.

Es ging darum, "." in den $PATH zu schreiben, um eben nicht mehr ./blablub, sondern nur noch blablub eingeben zu müssen. Und das wirds dann (nicht nur bei SuSE) gefährlich ( bzw. kann .... werden )

 

[doc]

ahh (ich sehs jetzt) ok sorry den post hab ich übersehen ... ja das sollt man besser nich machen.

 

[Jabo]

Naja bei SuSe Kann ich mir einiges vorstellen

Na, hat sich ja geklärt, wie's gemeint war... ich hatte den Text halt schnell griffbereit.

In der Tat kannst du (zumindest bei nicht mehr ganz taufrischer) SuSE in den Sicherheitseinstellungen von YaST mit einem Haken eintragen, daß du das möchtest. Daneben steht dann genau der gepostete Text.

Klar kann man das auch selber in die Config basteln, man könnte sogar selber auf die Idee kommen, aber ein Anfänger findet dann nicht genau solche Hinweise. Das ist gar nicht schlecht. Er lernt nicht sofort, wie er den Pfad manipuliert, aber daß *das* problematisch ist.

Der Text ist übrigens länger und sagt noch, daß das bei Unix-artigen Betriebssystemen so ist, beschränkt sich also nicht auf SuSE.

Ich meine in der Debian-Doku steht das auch, müßte ich jetzt suchen.

 

[doc]

ich bin noch nie auf die idee gekommen sowas zu machen, deswegen bin ich auch noch nie darüber gestolpert.

und suse naja da hab ich halt so meine Vorurteile aus grauer Vorzeit. ich weiss nich mal mehr genau warum, aber es war so prägend, das ich immer wieder gerne einfach so über suse herziehe (also mein suse gebla nich allzu ernst nehmen)

 

[Jabo]

ich bin noch nie auf die idee gekommen sowas zu machen, deswegen bin ich auch noch nie darüber gestolpert.

Vielleicht weil die Idee nicht so gut ist?

Gerade Umsteiger müssen diese Idee erst mal sehen, weil z.B. DOS (und das ist AFAIK bei cmd in neueren Windows' noch so) *zuerst* im aktuellen Verzeichnis sucht und mangels Erfolg *dann* erst in $PATH - und dann gab's noch Prioritäten zwischen *.bat oder *.com und *.exe. Man konnte dann lustige Sachen mit win.bat machen... und bei Unix läufst du gegen die Tür und die Nase wird blau. Das wollte ich begründen.

(also mein suse gebla nich allzu ernst nehmen)

Jo, tu ich auch nicht

ich hab da auch so meine eigene Meinug dazu, gerade wenn man z.B. eine SuSE neben Debian betreibt. $2 könnte auch was anderes sein... Die völlig eigene Geschichte mit /etc/sysconfig und die Tatsache, daß YaST/SuSEconfig dadurch manuelle Änderungen in *tatsächlichen* Config-Files überschreibt, ist sage ich mal hart an der Grenze von Genialtät zu Wahnsinn.

Man kann ja auch das manuell konfigurieren (also im Texteditor), wenn man weiß, welche Sachen *da* geregelt sind und dann tut man das eben da und nicht in /etc/eigentlich .... andererseits kannst du ne Menge dort in einheitlicher Syntax regeln, wozu du sonst quer durchs System hüpfen mußt, um an 3-4 Stellen Fehler zu machen auf dem Weg zu demselben Effekt.

Weil ich neben SuSE, das ich halt schon ne Weile kenne (5.3), auch andere Distries benutze (Debian z.B. seit Woody, im Moment Lenny), durchlebe ich das, was du da wohl meinst, öfters am eigenen Leibe mal... und zu aktuellen Susis kann ich sowieso wenig sagen mangels Installation.

 

[doc]

hehe ja genau das wars is jetzt schon 10 jahre her, aber es scheint sich ja nich geändert zu haben, an der suse config bin ich verzweifelt, redhat war dann besser, debian schon fast perfekt, aber es gab immer wieder kleinere bis grössere probleme und nu naja meine signatur sagt alles

 

[gropiuskalle]

Die völlig eigene Geschichte mit /etc/sysconfig und der Tatsache, daß YaST/SuSEconfig dadurch manuelle Änderungen in *tatsächlichen* Config-Files überschreibt, ist sage ich mal hart an der Grenze von Genialtät zu Wahnsinn.

Neinein, das ist pure Genialität - denn würde /etc/sysconfig keine configs überschreiben, wäre das doch eine Attrappe. Man kann auf den /etc/sysconfig-Editor verzichten (und dann bleiben direkt angepasste configs auch erhalten), nur wenn man diese Möglichkeit nutzt, sollte man sich darüber im Klaren sein, was man damit tut: nämlich configs 'überschreiben'.

Ich vermisse /etc/sysconfig immer sehr, wenn ich mit einem anderen System arbeite.