1

yop,


J'ai installé une KDE 11.10 hier, pour profiter de ce fabuleux bureau : http://www.trinitydesktop.org/ love
Mais trêve de pub. Je n'arrive pas à paramétrer Bash de la même manière que je le fais sur mes autres distros.

Dans man (bash), on lit que /etc/profile est lu quand on démarre une session Bash.
Et dans ce fichier, j'ai ajouté ça :
# Added for GCC4TI
BASH_ENV = ~/.autoexec

Mon .autoexec contient ça ;
#!/bin/bash

.gcc4ti

Et enfin .gcc4ti :
#!/bin/bash

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

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

Donc a priori, j'ai tout ce qu'il faut pour pouvoir lancer tigcc dans n'importe quel shell.
Problème, quand je lance konsole, qui utilise Bash, TIGCC n'est pas défini. Et même pas BASH_ENV, alors que /etc/profile doit être lu, dixit la doc :
When  bash is invoked as an interactive login shell, or as a non-interactive shell with the --login option, it first reads and executes commands from the file /etc/profile, if that file exists.  After reading that
file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile, in that order, and reads and executes commands from the first one that exists and is readable.  The --noprofile option may be used when the  shell
is started to inhibit this behavior.

Hors, pour cet autre raison :
When bash is started non-interactively, to run a shell script, for example, it looks for the variable BASH_ENV in the environment, expands its value if it appears there, and uses the expanded value as the name  of
a file to read and execute.  Bash behaves as if the following command were executed:
       if [ -n "$BASH_ENV" ]; then . "$BASH_ENV"; fi
but the value of the PATH variable is not used to search for the file name.

il m'est absolument impératif d'avoir BASH_ENV défini.

Alors vers où chercher ? Comment se fait-il que BASH_ENV ne soit pas défini ?

Je poste ici mon /etc/profile, il est peut-être pas du tout standard après tout (même si sur au moins une autre de mes distros, le fichier est identique, mis à part le fait que les deux blocs soient en ordre inverse) :
# /etc/profile: system-wide .profile file for the Bourne shell (sh(1))
# and Bourne compatible shells (bash(1), ksh(1), ash(1), ...).

if [ -d /etc/profile.d ]; then
  for i in /etc/profile.d/*.sh; do
    if [ -r $i ]; then
      . $i
    fi
  done
  unset i
fi

if [ "$PS1" ]; then
  if [ "$BASH" ]; then
    # The file bash.bashrc already sets the default PS1.
    # PS1='\h:\w\$ '
    if [ -f /etc/bash.bashrc ]; then
      . /etc/bash.bashrc
    fi
  else
    if [ "`id -u`" -eq 0 ]; then
      PS1='# '
    else
      PS1='$ '
    fi
  fi
fi

# Added for GCC4TI
BASH_ENV = ~/.autoexec



Voilà, si vous avez une piste, ça m'évitera de me retaper la définition des variables pour GCC4TI à chaque fois...

Merci d'avance. smile

2

J'ai l'impression qu'IRC a des problèmes, donc c/c :
[21:56] <@Zeph> Folco ?
[21:56] <@Zeph> # Added for GCC4TI
[21:56] <@Zeph> BASH_ENV = ~/.autoexec
[21:56] <@Zeph> je sais pas si c'est une faute de copier/coller, mais je vois un espace entre BASH_ENV et le signe "="
[21:57] <@Zeph> c'est pas valide en shell, il faut tout coller [21:57] <@Zeph> (idem pour la valeur derrière)
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

3

Ok, merci bien. Figure-toi que j'ai décollé (avant c'était collé), parce que ça marche comme ça sur une autre de mes distros fou

Mais résultat des courses, même recollé : ça ne change rien sad

4

OK, il manque peut-être un export pour BASH_ENV (qui sinon ne va pas avoir d'effet une fois le script exécuté), et un espace entre "." et "gcc4ti" (si tu voulais bien le sourcer)
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

5

Ah...

Oui, je veux sourcer les fichiers, donc c'est ". .gcc4ti" qu'il faut mettre pour sourcer .gcc4ti ?

Et sinon, Bash exporte automatiquement BASH_ENV, c'est le principe de cette variable, c'est la seule qu'on retrouve quelque soit le type de shell lancé (interactif ou non). Mais bon, même si .gcc4ti n'est actuellement pas sourcé, il n'en reste pas moins que BASH_ENV devrait être défini, car je ne vois pas dans la doc de raison pour que /etc/profile ne soit pas lu...


Merci bien en tout cas.

6

Ah au temps pour moi pour BASH_ENV.

Sinon pour gcc4ti je n'ai pas trop compris ce que tu voulais faire, c'est un fichier qui s'appelle ".gcc4ti" et tu veux le faire exécuter par ton shell courant ? Si oui, c'est bien ". .gcc4ti" qu'il faut lancer. J'imagine que tu as déjà vérifié tous les droits de tes divers fichiers "profile" ?
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

7

Oui, je suis bien propriétaire des scripts, et ils sont exécutables.

En fait, $BASH_ENV devrait être ~/.autoexec, qui source ~/.gcc4ti, qui me définit des variables, modifie $PATH etc...

8

Tu aurais pas mis un espace entre BASH_ENV et = ?

9

Cf ./2 ?

TIGCC="/usr/local/share/gcc4ti" 
export TIGCC 
 
PATH="$PATH:$TIGCC/bin" 
export TIGCC


Le deuxième export est-il vraiment correct ?

Sinon, pour voir qui est exécuté, tu peux toujours mettre des "echo toto >> /tmp/test" dans les différents fichiers…
avatar
<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)

<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant

10

en plus de ça, tu peux également utiliser la commande "env" à différentes étapes de l'exécution de ton script, pour lister toutes les variables d'environnement définies jusqu'ici.
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

11

J’ai pas tout lu, mais il est faux que bash lit systématiquement /etc/profile : il ne le lit que quand c’est un shell de login, donc typiquement si tu te loggues en ssh ou en console, mais pas si tu lances un xterm.

Inversement les fichiers .bashrc sont lus seulement par les shells pas de login. C’est pour ça que je mets toujours un .bashrc qui contient juste la ligne
. /etc/profile

comme ça j’ai un seul fichier à tenir à jour

sinon je sais pas si c’est exprès que tu n’exportes pas BASH_ENV ? (il faut l’exporter pour que ce soit une variable d’environnement)
avatar
« Le bonheur, c'est une carte de bibliothèque ! » — The gostak distims the doshes.
Membrane fondatrice de la confrérie des artistes flous.
L'univers est-il un dodécaèdre de Poincaré ?
(``·\ powaaaaaaaaa ! #love#

12

flanker (./9) :
Le deuxième export est-il vraiment correct ?

Ah, ok merci cheeky
Sally (./11) :
sinon je sais pas si c’est exprès que tu n’exportes pas BASH_ENV ? (il faut l’exporter pour que ce soit une variable d’environnement)

Je l'ai jamais fait sur mes autres distros, et ça marche très bien comme ça grin
Sally (./11) :
Inversement les fichiers .bashrc sont lus seulement par les shells pas de login. C’est pour ça que je mets toujours un .bashrc qui contient juste la ligne

Marrant, c'esd à ça que sert BASH_ENV en fait cheeky

13

(y'a une phaute dans le titre du topic)
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) // topics/6238-moved-jamais-jaurais-pense-faire-ca

14

Folco (./12) :
Marrant, c'esd à ça que sert BASH_ENV en fait mod.gif :: Editer posticon.gif :: Citer
Ce n’est pas ce que dit la page man :
man bash :
When bash is started non-interactively, to run a shell script, for
example, it looks for the variable BASH_ENV in the environment, expands
its value if it appears there, and uses the expanded value as the nameof a file to read and execute.
Certes ça ne dit pas explicitement que BASH_ENV est ignoré quand le shell est interactif, mais a priori c’est sous-entendu cheeky. Je n’ai jamais utilisé cette variable donc j’en suis pas sûr, mais ça me paraît assez clair.

A priori il y a vraiment trois cas avec des comportements complètement disjoints, c’est pénible et tordu (sans doute pour des raisons historiques de 30 ans de compatibilité) mais si tu lis ce que dit le man bash sous invocation c’est expliqué assez clairement je trouve :

— shell de login : il lit /etc/profile, ~/.bash_profile, ~/.bash_login et ~/.profile successivement *mais pas* ~/.bashrc
— shell interactif pas de login (le cas typique du xterm) : il lit ~/.bashrc et *c’est tout*
— shell non interactif (pas de login) : il lit $BASH_ENV si c’est défini et c’est tout

plus le cas à la con :
— shell non interactif lancé avec --login : j’ai jamais testé et c’est pas totalement clair, mais en tout cas il lit tous les profile et je suppose qu’il lit aussi $BASH_ENV en plus (mais je sais pas dans quel ordre)
avatar
« Le bonheur, c'est une carte de bibliothèque ! » — The gostak distims the doshes.
Membrane fondatrice de la confrérie des artistes flous.
L'univers est-il un dodécaèdre de Poincaré ?
(``·\ powaaaaaaaaa ! #love#

15

Bon, ben j'ai utilisé .bashrc et .profile pour faire ce que je voulais, tout simplement. Merci bien.

Mais ce n'est qu'un workaround, BASH_ENV devrait être défini, et l'est sur mes autres distros, je ne comprends pas pourquoi là, ce n'est pas le cas... confus