yop,


J'essaye de relancer gcc4ti en ligne de commande pour la première fois depuis un bail suos Win XP.
Quand je tape "tigcc" dans un shell, j'obtiens ça :

'tigcc' n'est pas reconnu en tant que commande interne 
ou externe, un programme exécutable ou un fichier de commandes.

Et j'ai rebooté depuis l'installation. Est-ce normal ? Je croyais avoir déjà invoqué tigcc sous Win en ligne de commande, sans problème.


Ca semble pas être trop grave, je dois pouvoir rajouter le path vers tigcc dans le path du système (ou de mon user, ça doit être mieux).
Au passage, c'est pas recommandé de mettre program files dans le path sous Windows ?

Folco (./0) :
Au passage, c'est pas recommandé de mettre program files dans le path sous Windows ?

Ben ça ne va pas t'aider beaucoup, les sous-répertoires du %PATH% ne sont pas explorés. Donc à moins que t'installes directement tout dans Program Files sans créer de sous-répertoires...

Ah ok c'est pas récursif, donc faut que j'ajoute à la main les répertoires des programmes que je veux lancer en ligne de commande, merci.

Erf, si je définis PATH pour mon compte, ça va overrider les paramètres systèmes, les compléter, ou créer un problème ?
J'aime pas donner des droits au système à tout bout de champs.

Yep (mais c'est pareil sous Linux, non ?)

J'ai édité. Oui, je crois que c'est pareil, mais je me suis pas posé la question (/usr/bin:~/bin powa )

Bizarement, quand je lance une console depuis le menu démarrer (Exécuter : cmd), j'arrive à invoquer tigcc.
Quand j'utilise le menu Outils de Code::Blocks (qui permet de lancer différents programmes externes, ça doit être assez classique comme menu), ben ça fait comme si j'avais pas rajouté "program files\gcc4ti" dans le path.

Voici le screen des deux consoles juxtaposées :
Fichier joint : (console.png)

Une idée d'où ça pourrait venir ?

Tiens, je retrouve ce vieux script dans eexec :

echo off 
 
tigcc -v eexec.s -o eexec 
 
move eexec.??z ../ 
 
del *.o *.??z

Je pense que ça marchait.

"#" n'est pas reconnu en tant que commande interne -> on dirait que tu exécutes un script shell sh sur Windows ?
Est-ce que tu as ajouté $TIGCC au PATH global du système, puis démarré C::B ?

(Folco : qu'est-ce que tu essaies de cacher sur ton screenshot ? )

Lionel Debroux (./7) :
"#" n'est pas reconnu en tant que commande interne -> on dirait que tu exécutes un script shell sh sur Windows ?

Je me suis loupé, l'habitude

Lionel Debroux (./7) :
Est-ce que tu as ajouté $TIGCC au PATH global du système, puis démarré C::B ?

Ah non, j'ai pas défini cette variable, j'ai juste ajouté "c:\program files\gcc4ti" à %PATH%.
Je vais essayer en modifiant le path ET en rajoutant la variable %TIGCC%

Zerosquare (./8) :
(Folco : qu'est-ce que tu essaies de cacher sur ton screenshot ? )

Rien, je crois qu'il y a un très vilain pirate qui a patché le binaire de ma console, c'est du beau ça (d'ailleurs je me suis loupé, le "3.0" n'a rien à faire là )

Mouais

Je pense à un truc, il ne faut pas des guillemets autour de C:\Program Files\gcc4ti ? (il y a une espace dedans)

Folco (./5) :
Une idée d'où ça pourrait venir ?

As tu relancé code blocks ? La console qu'il lance hérite probablement de son environnement.

Bon, j'ai essayé vos suggestions (ajout de %TIGCC% dans les variables système, pas locales), ajout de guillemets pour définir cette variable (à noter que %PATH% n'en a pas besoin), rien n'y fait :
Fichier joint : (console.png)

Tu as pensé à redémarrer la console après avoir édité la variable? Ou peut-être redémarrer windows, mais la je suis moins sur.

Oui. Rien n'y fait, je dois rater un truc.

Dans ces deux consoles, taper la commande "path" (toute seule sans argument ni espace à la fin) renvoie la même chose ? (au caractère près)

Code Blocks n'aurait pas un paramètre de rédéfinition du path ?

Dans les chemins de ton path(et dans l'ordre), y'aurait pas un path.exe, .cmd ou .bat qui trainerait ?

On peut voir le contenu de build.bat ?

Essaie d'installer Gcc4ti dans un nom de répertoire sans espace pour voir. Le fait que "Program Files" soit en deux mot est un problème récurent sous windows.

Ou alors tu utilises progra~1 comme nom (le 1 devant être remplacé par le bon si tu as plusieurs noms longs)

Je teste vos pistes. J'ai des résultats différents pour

echo %path%

Sous C::B :

c:\Program Files\Codeblocks\Mingw\bin;c:\Windows\system32;c:\windows;c:\windows\system32\webm

Et sur le Bureau :

c:\Windows\system32;c:\windows;c:\windows\system32\webm\c:program files\gcc4ti

Je vais voir sur le forum de C::B pourquoi il s'évertue à modifier le path sans mon accord.

Merci pour toutes vos réflexions et conseils.

il semblerait que tu aies un smiley au milieu de ton path, le problème vient sans doute de là

(effectivement, on dirait qu'il écrase carrément le path d'origine au lieu de concaténer )

( )
(corrigé)

je ne sais pas si ça vient de la correction mais tu pourrais confirmer qu'en vrai tu as un point virgule après webm\ ?

Je confirme, problème de recopie, mais bien vu

Bon, problème trouvé. J'utilise ça : http://rocketdock.com/

Il se trouve que ce launcher doit garder un snapshot des variables d'environnements quand on l'installe, car C::B n'est pas dans le même environnement quand je le lance depuis le menu démarrer ou le dock.
La suppression/réinstallation de RocketDock corrige le problème.

Voili voilou, merci à tous pour tout, vos pistes, et ce que j'ai encore appris grâce à ce problème.

Bon, puisqu'il m'arrive la même chose, mais sur ma Debian, je reviens vers vous (heureusement que j'ai pas mis l'OS dans le titre, ça permet de recycler ^^)

Configuration de l'environnement :

$ echo $SHELL 
/bin/bash 
$ echo $PATH 
/home/folco/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:[b]/usr/local/share/gcc4ti/bin[/b] 
$ echo $TIGCC 
/usr/local/share/gcc4ti

Tout semble normal.
$TIGCC est défini dans mon .bashrc, $PATH y est complété (je l'ai fait à la main, mais a priori c'est la même chose que ce que fait le script d'install, de toute façon les variables me semblent bonnes).

Dans un shell (gnome-terminal ou xterm) :

$ tigcc 
tigcc: no input file

Et je peux assembler des programmes, donc le path et $TIGCC sont bien bons.


Configuration de Code::Blocks :
J'utilise un outil pour me lancer mon script de build (en-tête : #!/bin/bash). Les paramètres de l'outil sont :
exécutable : ./build.sh
path : ${PROJECT_DIR}


Problème :
Si mon script invoque directement `tigcc' :
./build.sh: line7: tigcc: command not found [...]

Si mon script invoque `/usr/local/share/gcc4ti/bin/tigcc' :
Fatal error: TIGCC is not defined in the environment [...]


Alors que se passe-t-il ? J'ai paramétré C::B pour me lancer par défaut bash dans un xterm quand il me lance un shell. Qu'est-ce qui ne va pas ? Mon .bashrc semble complètement ignoré... Ca fait une heure que je piannote, je trouve rien...


(et encore, au début, je croyais que c'était parce que j'utilisais un trick pour faire faire un --noclose à gnome-terminal qui ne propose pas l'option, mais même pas : j'obtiens le même comportement avec un simple xterm lancé sans paramètres)

Vos avis et pistes vers lesquelles chercher sont les bienvenus, je vous en remercie d'avance.

Essaie d'ajouter un "source ~/.bashrc" explicite dans ton build.sh.

Même erreur, quelque soit l'invocation à tigcc.

Ca, c'est plus bizarre...

Et donc même quand je mets `TIGCC=/usr/local/share/gcc4ti' dans mon script, juste avant l'invocation à tigcc, j'ai le même message "TIGCC not declared in the environment [...]"

Autres indices :
Quand je dis à C::B de me lancer un terminal, et que moi-même je table ./build.sh, ça marche. Les variables globales sont bonnes.
Quand je dis à C::B de me lancer ça : /bin/bash -c './build.sh, ça ne marche pas non plus.

Que puis-je fournir encore, comme indices, pour établir un diagnostic ?