Ce n'est pas un problème si tu est "l'administrateur" du système et surtout si le script sert à tout les utilisateur de la machine. Là, ce script est prévu pour un utilisateur bien précis, il n'a rien à faire dans un répertoire globale de la machine. De toutes manières, il n'a rien à faire dans le PATH car il n'est pas indépendant du chemin d'accès et il doit donc se trouver dans le dossier du projet.

DarKwings : faire passer un programme userland en systemland c'est véroler la machine. Si ta petite sœur mets un script 'sl' qui fait '/bin/rm -fr ~' dans /usr/bin, j'aimerais voir ta tête le jour ou tu fera une type su ls.

Ce que tu me sites n'a doublement rien à voir :
1) /proc/cpuinfo et /usr/local/bin/ckoimoncpu sont tous les deux systemland
2) même si tu rend /proc/cpuinfo exécutable, ça ne fera rien puisque c'est un fichier plain text sans shebang.

dnob700 : ça dépend. On peut supposer que le script est suffisamment général (utilisation de pwd et autre) pour être lancé depuis n'importe où. Dans ce cas, il faut le mettre dans ~/bin.

Il n'y a pas besoin de supposer quoi que ce soit : bob63 a uploadé les fichiers en question.

J'ai eu la flemme d'y jeter un coup d'œil.

désolé du retard.
J'ai commencer en septembre, je vous explique, le soucis c'est qu'à notre IUT, différemment des autres, jusqu'au mois dernier on nous à appris le langage ADA parce qu'il est plus chiant que le C, on a donc vu le C en un mois (pas fabuleux je vous l'avoue du fait qu'on capte rien ) et donc maintenant le c++ .. c'est pour cela que tout est mâché et on nous simplifie la vie Du coup maintenant vu qu'on a tout vu très vite, j'aimerais programmez chez moi pour m'entrainer quoi ...

Chris> C'est /usr/local/bin/ckoimoncpu que je rend executable dans cet exemple, pas cpuinfo.

Concernant ta réponse, si tu file le mdp root ou les droits necessaires a ta soeur pour qu'elle écrive dans /usr/local/bin, c'est ton problème non?

Je veut dire que je parle bien de mettre dans ce répertoire un script dont tu as vérifier le contenu, en tant qu'admin de la machine.

bob63> IUT de Dijon non?

DarKwings : d'une part, tu n'es pas toujours admin de ta propre machine (par exemple, c'est toi qui pourrait faire ce coup vache à ta sœur si elle n'a pas les droit root). D'autre part, ce n'est pas parce que tu es admin qu'il faut forcément ce servir de ces droits là.

Ce que je constate de cette discussion, c'est que tu n'as rien compris. Puisque que tu te sens tout puissant avec tes droits d'admins, continue donc à polluer ton systemland avec des choses purement userland. C'est toi que ça regarde après tout.

Le problème est le même que pour la porté des variables (pour rapprocher ce que dit chris du sujet du forum) : seules les variables effectivement utilisées partout dans le programme doivent être globales, les autres sont locales, voire déclarées avec une porté encore moindre si c'est possible.

Ce que veut dire chris, c'est que pour les programmes c'est pareil : un programme utile à tout les utilisateur va dans /usr/local/bin (c'est par exemple le cas de ton script ckoimoncpu), mais un programme propre à un utilisateur va dans son home (~/bin par exemple), voir dans un dossier précis si le programme est propre à un dossier (dans le cas qui nous intéresse).

Ensuite, de toutes manières, chacun fait ce qu'il veut avec ce qui lui appartient.

Justement je ne vois pas en quoi un script, qui compile les fichiers dont le chemin est en argument, est quelque chose de spécifique a un utilisateur.
C'est pour moi quelque chose qui peut tout autant servir aux autre, sauf si le chemin de son home est écrit en hard dans le script, mais ça c'est une erreur de conception du script.

En même temps, je l'ai dit 36 fois que le script en question est effectivement très très spécifique vu qu'il faut qu'il soit appelé depuis un dossier qui contient exactement les bibliothèques utilisées dans l'iut qui les as fourni et qu'il n'a donc absolument aucune généralité.

Savoir si c'est une erreur de conception du script n'est pas la question.

bob63 : il faudrait que tu lise un cours de base de C ou de C++ juste pour apprendre ces points sur la programmation. Ensuite, tu pourra continuer un utilisant les cours que tu as à ton iut.

Le premier chapitre du cours de C du site du zéro devrait suffire à comprendre les principes de la compilation ;-)

bob63, je ne sais pas quel est ton plan de carrière, mais en SSII ce qui est à la mode en ce moment, c'est le JAVA. Alors certes avec les IDE tu n'auras probablement jamais à compiler manuellement. Mais si tu veux survivre dans le monde de l'informatique, il te faudra très probablement regarder plus loin que ce que t'offre ta formation. (et c'est le principe du DUT de former des types qui savent utiliser man/google/whatever). Le fait que tu cherches à aller plus loin que tes cours en bossant chez toi est un bon point, continue comme ça ;-)

Mon plan de carrière je sais pas trop encore, je fais mon dut en fait voir la où je me débrouille le mieux, il est vrai qu'en c++j'ai quelques difficulté quand même,surtout avec les commandes unix pour compiler et tout ça (après suffit de bien les apprendre et voilà).

Sinon si je me met dans mon dossier cplus que je tape "./compclasse" sa me met :
g++ : .cpp : aucun fichier ou dossier de ce type
g++: pas de fichier à l'entrée

Pourtant g++ est installé, pourquoi sa marche pas ?

J'ai installer libgtk2.0, g++, gcc (mais il l'était déjà), build-essential (idem), comment faire pour pouvoir utiliser ce compclasse et compile?

merci

upload quelque part le script en question (sur un wall (http://rafb.net/paste par exemple), pas surun site fatiguant) pour qu'on puisse regarder.

bob63 : vu le message d'erreur, c'est pas l'absence de g++ le problème.

« .cpp : aucun fichier ou dossier de ce type » g++ veut compiler le fichier ".cpp" mais ne le trouve pas. C'est probablement ton script qui ne marche pas comme il devrait.