- Posted On the 2011-09-10 at 05:24 pm Member since 2001-06-18, 30548 posts
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 ?
avatar <<< Kernel Extremist©®™ >>>
Saint Qt, priez pour nous.
- Posted On the 2011-09-10 at 07:02 pm Member since 2001-06-10, 2060 posts
Essaye avec "export TIGCC=..." dans ton script.
So much code to write, so little time.
- Posted On the 2011-09-10 at 07:22 pm Member since 2001-06-18, 30548 posts
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...
avatar <<< Kernel Extremist©®™ >>>
Saint Qt, priez pour nous.
- Posted On the 2011-09-10 at 07:39 pm Member since 2001-11-11, 109211 posts
Folco (./30) :
Que puis-je fournir encore, comme indices, pour établir un diagnostic ?

Une IRM du pancréas du patient
avatar Webmaster du site Ti-FRv3 (et aussi de DevLynx)
Si moins de monde enculait le système, alors celui ci aurait plus de mal à nous sortir de si grosses merdes !
"L'erreur humaine est humaine"©Nil (2006) // http://www.yaronet.com/posts.php?s=6238
- Posted On the 2011-09-10 at 08:09 pm Member since 2001-06-18, 30548 posts
Tu mates trop Dr House toi grin
avatar <<< Kernel Extremist©®™ >>>
Saint Qt, priez pour nous.
- Posted On the 2011-09-10 at 08:23 pm Member since 2001-11-11, 109211 posts
tu crois ?
avatar Webmaster du site Ti-FRv3 (et aussi de DevLynx)
Si moins de monde enculait le système, alors celui ci aurait plus de mal à nous sortir de si grosses merdes !
"L'erreur humaine est humaine"©Nil (2006) // http://www.yaronet.com/posts.php?s=6238
- Posted On the 2011-09-10 at 08:42 pm Member since 2001-06-18, 30548 posts
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. bang
avatar <<< Kernel Extremist©®™ >>>
Saint Qt, priez pour nous.
- Posted On the 2011-09-11 at 12:19 am Member since 2001-06-11, 19256 posts
Utilise un éditeur digne de ce nom, et pas çà.
- Posted On the 2011-09-11 at 12:42 am Member since 2001-11-11, 109211 posts
(tu en as un à recommander ?)
avatar Webmaster du site Ti-FRv3 (et aussi de DevLynx)
Si moins de monde enculait le système, alors celui ci aurait plus de mal à nous sortir de si grosses merdes !
"L'erreur humaine est humaine"©Nil (2006) // http://www.yaronet.com/posts.php?s=6238
- Posted On the 2011-09-11 at 12:43 am Member since 2001-06-18, 30548 posts
Emacs cheeky

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é. grin
avatar <<< Kernel Extremist©®™ >>>
Saint Qt, priez pour nous.
- Posted On the 2011-09-11 at 02:02 am - Edited by Folco On the 2011-09-11 at 12:31 pm Member since 2001-06-18, 30548 posts
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. smile
avatar <<< Kernel Extremist©®™ >>>
Saint Qt, priez pour nous.
- Posted On the 2011-09-11 at 10:50 am Member since 2001-11-11, 109211 posts
La guerre en Afhanistan.
avatar Webmaster du site Ti-FRv3 (et aussi de DevLynx)
Si moins de monde enculait le système, alors celui ci aurait plus de mal à nous sortir de si grosses merdes !
"L'erreur humaine est humaine"©Nil (2006) // http://www.yaronet.com/posts.php?s=6238
- Posted On the 2011-09-11 at 11:04 am Member since 2001-06-10, 6929 posts
et tout simplement déclarer la variable et le path dans ton .profile ou .bash_profile, ca marche pas?
avatar
- Posted On the 2011-09-11 at 11:19 am Member since 2001-06-18, 30548 posts
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.
avatar <<< Kernel Extremist©®™ >>>
Saint Qt, priez pour nous.
- Posted On the 2011-09-11 at 12:48 pm Member since 2001-06-18, 30548 posts
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 ?
avatar <<< Kernel Extremist©®™ >>>
Saint Qt, priez pour nous.
- Posted On the 2011-09-12 at 01:27 am Member since 2006-04-27, 43997 posts
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)
avatarZeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo
- Posted On the 2011-09-12 at 10:48 am Member since 2001-06-18, 30548 posts
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 ^^
avatar <<< Kernel Extremist©®™ >>>
Saint Qt, priez pour nous.