`tigcc' not found - Page 2

Essaye avec "export TIGCC=..." dans ton script.

Même diagnostic.

C::B exécute précisément ça :
Launching tool 'Build': xterm -T 'Build' -e /usr/local/bin/cb_console_runner ./build.sh (in /mnt/Data/Programmation/TI/Perso/pdt/as/src)
Je sais pas ce que fabrique ce cb_console_runner, mais quand je lance à la main build.sh dans un xterm, ça marche très bien...

Folco (./30) :
Que puis-je fournir encore, comme indices, pour établir un diagnostic ?

Une IRM du pancréas du patient

Tu mates trop Dr House toi

tu crois ?

Bon, ça a l'air d'être tordu du string du côté de chez C::B. Je découvre, mais je suis vraiment ébahi.
Donc cb_console_runner à l'air de se foutre pas mal des variables d'environnement. J'aime les programmes qui se la jouent perso et qui se branlent du contexte.

Je vais donc dans le menu "Settings -> Environment -> Environment variables".
Et là, je redéfinit $TIGCC. Miracle ! Quand j'appelle /usr/local/share/gcc4ti/bin/tigcc, ça marche. C'est bon j'ai trouvé !
Enhardi par ce succès, j'ose rajouter PATH=$PATH:$TIGCC/bin

Et là manque de pot, ça merde. Les bras et le moral retombent.


Bon, ben retour vers les forums de C::B. Ya certainement une explication surgéniale au fait qu'un programme se branle de la configuration de l'environnement, et oblige à redéfinir exactement la même chose (mais pas tout à fait, faut qu'il y ait un truc qui déconne quand même) en parallèle.
Et déjà, il faut respécifier à C::B le shell qu'on utilise. Plutôt que d'utiliser le shell associé à mon login, non, monsieur préfère sh, et il faut lui demander pour qu'il utilise bash. Et même quand il daigne le faire, c'est bash sans sa configuration qu'il utilise. Comprends rien moi.

Utilise un éditeur digne de ce nom, et pas çà.

(tu en as un à recommander ?)

Emacs

J'ai utilisé et j'y repense ^^


En fait, ça viendrait comme d'habitude de moi. Indice donnés pas Jens sur le forum de CB, merci à lui : quand bash est lancé de manière non interactive (non dans un terminal (option -i), mais pour interprêter un fichier comme c'est le cas ici), il ne tient pas compte des différents bashrc (ni dans /etc, ni dans ~).
Le seul script utilisé sera /etc/profile. Donc il est normal que les variables définies dans mon ~/.bashrc ne soient pas définies quand bash est appelé pour lancer directement mon script (comme c'est le cas ici, je demande à xterm de faire exécuter build.sh par bash, et pas de me lancer un bash en mode interactif).

De là, je vois deux solutions :
- sourcer /etc/bashrc dans /etc/profile (et non /etc/bash.bashrc, parce que ce script quitte explicitement s'il est lancé en mode non interactif, au moins sous Debian)
- définir la variable $BASH_ENV pour la faire pointer vers /etc/bashrc, parce que bash exécute le script pointé par cette variable s'il est exécuté en mode non interactif.

La doc ici : http://pwet.fr/man/linux/commandes/bash

Maintenant, je vais essayer tout ça. Mais ça fait plaisir, j'avais toujours évité de mettre les doigts dans ces fichiers de conf parce que ça me plaisait pas, mais là je suis bien obligé.

Bon, donc après moultes essais, c'est le triomphe, tout marche comme attendu et j'ai compris comment ça marche \\o///

J'ai donc :

- hardcodé path et variables dans /etc/profile. Evidemment ça marche, mais c'est dégueu. Poubelle.

- sourcé /etc/bashrc dans /etc/profile. Ca marche, mais ça fait une définition de PATH et de TIGCC dans /etc/bashrc, une autre dans ~/.bashrc. Poubelle.

- sourcé ~/.bashrc dans /etc/profile. En plus de devoir faire sauter la protection de ~/.bashrc qui veut pas s'exécuter dans un shell non interactif, c'est encore plus crade que la première solution, vu que mon bashrc perso devient system wide. Ca marche, mais poubelle avec malédictions sur les 7 prochaines générations

- Enfin, la solution retenue. Je la mets, elle peut servir à d'autres :
dans /etc/profile :
BASH_ENV=~/.gcc4ti
dans /etc/.bashrc, rajouter :
. ~/.gcc4ti
créer ~/.gcc4ti :

#!/bin/bash

TIGCC="/usr/local/share/gcc4ti"
export TIGCC

PATH="$PATH:$TIGCC/bin"
export TIGCC

Voilà, comme ça c'est à peu près propre :
- il n'y a pas d'informations globales au système pour les shell de logins ou les shell interactifs.
- les données concernant gcc4ti sont centralisées dans un seul fichier de mon répertoire personnel
- BASH_ENV est défini avec ~, donc les données de gcc4ti ne sont définies que sous mon login, c'est bien.

Voilà donc, maintenant ça marche au poil, et si ya quelque chose que j'ai raté, n'hésitez pas.

La guerre en Afhanistan.

et tout simplement déclarer la variable et le path dans ton .profile ou .bash_profile, ca marche pas?

Je pense que non, il faudrait que bash soit lancé avec --login pour que .profile soit lu. Mais j'ai pas essayé.
Le seul fichier dont on soit sûr de l'exécution quand un bash non itneractif est lancé est le script ponité par BASH_ENV.

Il y a même un --noprofile qui désactive la lecture des *profile, alors que rien ne semble prévu pour désactiver la lecture de BASH_ENV.

Bon, vu que ma solution à base de .bashrc marche, il faut absolument que je la modifie, sinon ça va continuer à marcher et je pourrai utiliser mon PC.

Plus sérieusement, j'ai des problèmes de concept :

Problème n°1 :
La valeur de la variable que j'ai installé dans /etc/profile est "~./gcc4ti". Ca se passera toujours bien sur mon système, mais unix étant conçu multi-utilisateurs, c'est débile. Qui d'autre voudrait d'un .gcc4ti dans son ~ ? Personne.
Il serait donc plus judicieux de donner par exemple "~/.autoexec" comme valeur à ENV_VAR. Après, libre à chaque utilisateur de se définir un .autoexec si ça l'amuse, et d'en faire ce que bon lui semble.


Problème n°2 :
J'ai centralisé dans .gcc4ti la mise en place de variables. Du coup, ce script est lancé quelque soit le type d'invocation de bash : shell interactif, shell de login, shell non interactif. Alors que précisément, Monsieur Bash s'est ingénié à ce qu'on puisse automatiquement avoir des paramètres différents suivant les modes d'utilisation de bash, ce qui est au demeurant fort commode.

Donc idéalement, il faudrait mettre la configuration de GCC4TI :
- dans .bashrc
- dans .autoexec

Mais pour ne pas maintenir ça en double, je pourrais tout simplement faire un .gcc4ti appelé par ces deux scripts.



Que pensez-vous de tout ça, question concept et logique ?

Pourquoi ne pas lancer simplement ton .autoexec à partir de ton .bashrc ? (.autoexec serait alors un fichier qui contiendrait les trucs à lancer quelque soit la façon dont tu démarres le shell)

C'est le problème que je tende de défricher dans le n°2. Bash sépare la configuration pour chacun de ses types de lancement, et n'a pas de fichier de configuration commun. Créer une configuration commune, c'est un peu court-circuiter ce principe. Mais c'est pourtant ce que je cherche. Ahlala, c'est pas simple d'être sûr du bon concept ^^