[Résolu] Execution d'un script depuis .profile

JujuLand · Le 20/12/2017, à 15:10

Bonjour,

J'utilise depuis bien longtemps un script de ma fabrication qui déclare des variables globales. Pour avoir ces variables globales, je lance ce script depuis le .profile, et tout fonctionnait très bien jusqu'à ce que je fasse une modification apparement mineure au script.

Voici la version initiale:

#!/bin/bash

# Définition des couleurs
# Arrière-plan
export bBla='\033[40m'
export bRed='\033[41m'
export bGre='\033[42m'
export bYel='\033[43m'
export bBlu='\033[44m'
export bMag='\033[45m'
export bCya='\033[46m'
export bWhi='\033[47m'
# Normal
export fBla='\033[30m'
export fRed='\033[31m'
export fGre='\033[32m'
export fYel='\033[33m'
export fBlu='\033[34m'
export fMag='\033[35m'
export fCya='\033[36m'
export fWhi='\033[37m'
# Normal
export gBla='\033[1;30m'
export gRed='\033[1;31m'
export gGre='\033[1;32m'
export gYel='\033[1;33m'
export gBlu='\033[1;34m'
export gMag='\033[1;35m'
export gCya='\033[1;36m'
export gWhi='\033[1;37m'
# Sans couleur
export noColor='\033[0m'
# Déplacements sur l'écran:
export mho='\033[0H'
export men='\033[0F'
export mle='\033[0D'
export mri='\033[0C'
export mup='\033[0A'
export mdo='\033[0B'

La modification a juste consisté à ajouter ces quelques lignes en début de script:

version=1.00

if [ "x$1" != "x" ];then
   echo -e "ii\tcolors\t$version"
   exit
fi

Ca fonctionne très bien connecté, mais à la connexion, çà plante depuis .profile et çà me ramène à l'écran de connexion...
Dans .profile, le script est lancé par :

. colors

J'ai fait cette modif pour un ensemble de scripts pour mon logiciel de maintenance, mais c'est la seule qui est lancée sous .profile
Je me demande si çà ne vient pas de $1 qui est inexistant
Je m'en suis sorti de la sorte, vu que je me sers de cette fonctionnalité juste à partir d'un script quio liste les scripts et leur version.

#ii:colors:1.00

Et j'utilise çà comme çà:

cat $(which colors)|grep ":colors"|sed 's/#//g'|sed 's/:/\x09/g' |cut -f1,2,3 |awk '{print $1"  "$2"            "$3}' >> ~/serveur-versions

Ca le fait, mais je me demande ou j'ai pu me planter avec la variable $1
Si quelqu'un a une idée ...

Merci
A+

Dernière modification par JujuLand (Le 20/12/2017, à 21:55)

Watael · Le 20/12/2017, à 15:28

salut,

La modification a juste consisté à ajouter ces quelques lignes en début de script

à quoi devraient servir ces lignes ?

JujuLand · Le 20/12/2017, à 15:32

Oui, seule modif.

Pour afficher la version du script. Pas primordial, mais ça me permet de voir si les scripts qui sont installés sur les machines que je maintiens sont à niveau.

Le fait de lancer le script avec <point><espace<devant doit y être pour quelque chose?

A+

Watael · Le 20/12/2017, à 16:32

mais pourquoi tester que le script a un argument ?

JujuLand · Le 20/12/2017, à 16:40

Ouais, c'est vrai dans ce cas là, mais j'ai d'autres scripts où il ne me faut pas ce type de sortie ... j'ai un peu standardisé leurs structures ...

Mais le problème n'est pas tant le pourquoi de l'argument ou non, mais celui du plantage à partir du .profile, et semble-t-il dans le cas (je n'ai pas testé) du lancement avec point et espace devant, dont si j'ai bien compris l'intérêt, est de permettre de globaliser les variables définies.

C'est juste pour savoir, vu que ce n'est pas bloquant et que j'ai une solution qui fonctionne ...

A+

JujuLand · Le 20/12/2017, à 16:53

Je viens de regarder une doc:

L'appel par le point qui consiste à saisir le nom du script depuis le répertoire ou se il trouve, précédé d'un point
et d'un espace (par exemple : ". script"). Ainsi, le script est exécuté par le shell et dans l'environnement courant;
il n'y a pas de lancement de sous-shell.

Je viens de refaire le test en réinsérant le test dans une console (et bien sûr en enlevant le exit), et çà ne plante pas dans les deux cas.

C'est donc durant l'exécution du .profile, à la connexion que çà pose problème ...

Dernière modification par JujuLand (Le 20/12/2017, à 16:56)

ar barzh paour · Le 20/12/2017, à 17:25

je ne sais pas ce qui se passe mais voilà ce que j'ai fait :
j'ai créé un fichier profile que j'ai mis dons $HOME

#!/bin/bash
version=1.00

if [ "x$1" != "x" ];then
   echo -e "ii\tcolors\t$version"
   # exit
   else
   echo "2 ème solution"
fi

j'ai ajouté en fin de .profile la ligne suivante

. profile

j'ai relancé ma session et j'obtiens le curieux effet suivant

la boite du bas est une boite zenity "normale" qui est provoqué par un script en autostart
ce qui est plus curieux c'est la barre du haut qui prend comme intitulé l'intitulé de ma boite zenity !!!!

mais comme il n'y a pas de tty dans ce cas ,je n'ai
ni le message ii colors 1.00
ni le message 2ème solution

Dernière modification par ar barzh paour (Le 20/12/2017, à 17:30)

Watael · Le 20/12/2017, à 17:45

voilà, voilà.
si tu sources un script qui contient une instruction exit, alors la session se termine !
parce que le script est exécuté dans le contexte courant, et non dans un sous-shell.

JujuLand · Le 20/12/2017, à 20:31

L'instruction exit n'est exécutée que et uniquement si $1 a une valeur, donc en lançant colors sans paramètre, le exit ne doit pas être exécuté.

Si effectivement $1 a une valeur, alors il le sera.

Je vais envoyer la valeur de $1 dans un fichier pour voir quelle valeur il pourrait avoir.

A+

pingouinux · Le 20/12/2017, à 20:42

Bonsoir,
Pour info, tu peux remplacer

if [ "x$1" != "x" ];then

par

if [ "$1" ];then

JujuLand · Le 20/12/2017, à 20:56

Bon, j'ai modifié colors de la façon suivante:

echo "Voici la valeur de  \$1 : [$1]" > ~/kelvaleur

Et au reboot, dans kelvaleur, j'ai ça:

alain@aupeix-GX723:~$ cat kelvaleur 
Voici la valeur de  $1 : [/home/alain/.profile]

Curieux que colors récupère cette valeur, c'est le chemin de .profile !!!

Maintenant, çà explique pourquoi ça exécute le exit, et que çà empêche la connexion.

En changeant le test, et en ne comparant pas $1 à une valeur non nulle, mais à une valeur définie, çà fonctionnera.

Merci
A+

Dernière modification par JujuLand (Le 20/12/2017, à 21:54)

JujuLand · Le 20/12/2017, à 22:00

ar barzh paour a écrit :

JujuLand a écrit :
j'ai ajouté en fin de .profile la ligne suivante
. profile

Je ne comprenais pas ton test ...

Je viens de comprendre en relisant ma prose initiale.
C'était pas . profile, mais . colors

Miile excuses pour cet étourderie ...

A+

ar barzh paour · Le 21/12/2017, à 11:40

je ne sais pas si le nom du shell importe , effectivement dans mon test j'avais appelé le shell "profile" d'où l'appel par . profile , je suppose maintenant que ton shell s'appelle "colors"

et si tu regardes mon shell j'avais diésé exit , donc soit j'aurai du avoir 1 , soit j'aurai du avoir 2
je pense que echo ne marche pas et qu'il faut faire appel à zenity pour afficher quelquechose

je viens de retester sur mon portable : conclusions :
mettre exit fait boucler le redémarrage !!!! donc attention aux testeurs , de pouvoir modifier le .profile ou le shell ajouté

echo ne fonctionne pas

zenity me renvoie bien un message

le système m'indique cependant une erreur gtk

Dernière modification par ar barzh paour (Le 21/12/2017, à 12:15)

JujuLand · Le 21/12/2017, à 12:15

Non; le nom n'a aucune importance, j'avais cru lire . .profile

Pour ce qui est du echo, il ne doit être utilisé que quand un paramètre est présent, et ce paramètre, je ne le positionne pas dans le .profile, et dans ce cas, il fonctionne.

Voici la version qui fonctionne:

version=1.00

if [ "x$1" = "x-v" ];then
   echo -e "ii\tcolors\t$version"
   exit
fi

Le problème venait du fait que, en execution dans .profile avec . colors, le paramètre $1 était encore présent (/home/alain/.profile)

Avec la version qui utilise un test positif, et non un test négatif, ça fonctionne.

La conclusion, c'est qu'il faut se rappeler que les scripts exécutés avec . sont dans le même shell, et héritent donc des variables déjà définies.

Pour ce qui est du echo dans .profile, il est normal qu'il ne fonctionne pas, car il n'y a pas de terminal ouvert lors de l'exécution de .profile

Je n'ai pas eu le besoin d'afficher durant le .profile, mais je m'en souviendrai en cas de besoin.
D'ailleurs, j'aurai pu utiliser zenity pour vérifier le contenu de $1

A+

ar barzh paour · Le 21/12/2017, à 12:30

oui c'est ce que j'en ai conclu , merci pour le rappel de la signification du "."
ce que je ne comprends pas dans ton script , c'est que
si "$1" prend la valeur "-v"
ton echo ne marchera pas ( avec ou sans paramètre , pas de résultat )
ton exit fera partir en boucle
alors à quoi ça te sert ?

JujuLand · Le 21/12/2017, à 12:50

Si $1 prend la valeur -v, c'est qu'on aura tapé la commande colors -v pour afficher la version du script colors.

J'utilise colors principalement dans .profile pour avoir les variables définies comme globales, et accessibles de n'importe où et n'importe quand. Et donc, évidemment, ce paramètre n'est pas utilisé dans le .profile

Je n'utilise ce bout de code, comme dit auparavant, que pour afficher la versions de tout un tas de scripts, et celui-la en même temps, dans un script nommé mversion qui lui n'est pas exécuté dans .profile.

Le exit utilisé dans ce cas ne sert, pour certains de ces scripts, que pour ne pas exécuter le script dans le cas de recherche de version, exemple dans ce script qui effectue les mises à jour, où l'on comprends aisément que la recherche de version ne doit pas s'accompagner de son exécution complète

#!/bin/bash

version=1.10

if [ "x$1" != "x" ];then
   echo -e "ii\tmisajour\t$version"
   exit
fi

sudo apt-get update
echo " "
echo -e "$gCya apt-get upgrade =>$noColor"
echo " "
sudo apt-get dist-upgrade
echo " "
sudo apt-get autoremove
echo " "
echo -e "$gCya Appuyez sur une touche pour fermer la fenêtre ...$noColor"
read

Donc, çà a un intérêt limité, hormis pour moi, de savoir si l'ordi distant que je maintiens a bien les scripts requis, et dans les dernières versions, car, si ce n'est pas le cas pour colors, certains scripts ont vu leurs versions modifiées un certain nombre de fois pour corriger tel ou tel bug, ou pour s'adapter à des configurations et versions de linux différentes.

Il est vrai, par ailleurs , que colors ne devrait pas trop changer ... et donc, j'aurai pu m'en dispenser dans ce cas.

A+

Dernière modification par JujuLand (Le 21/12/2017, à 12:56)

Watael · Le 21/12/2017, à 15:28

il n'y a pas de terminal ouvert lors de l'exécution de .profile

si.
.profile est exécuté à l'ouverture d'un terminal.

JujuLand · Le 21/12/2017, à 16:22

Watael a écrit :

si.
.profile est exécuté à l'ouverture d'un terminal.

Faux !!!

Pour le prouver, j'ai modifié le fichier .profile, et ai remplacé . colors par colors (et donc colors est alors exécuté dans un sous-shell).

Lorsque je teste cette ligne dans un terminal que j'ouvre, c'est sans couleur, malgré ce que dit la ligne

alain@Gramps-JujuLand:~$ echo -e "$gGre C'est bien en couleur$noColor"
 C'est bien en couleur

Ceci prouve :
1) que les variables qui sont créées dans un sous-shell sont perdues à la fermeture du terminal dans lequel elles ont été définies, et que si on veut les conserver, il faut les lancer avec le point. Ce qu'on savait déjà !
2) que .profile n'est pas lancé à chaque ouverture de terminal.
3) que si lancé en mode point, dans un terminal, mais pas dans .profile, les variables n'existent pas dans un nouveau terminal, et que leur portée n'est pas globale, et donc, pour pouvoir en bénéficier de manière globale, sans avoir à les recréer chaque fois, il faut les lancer en mode point et dans le .profile.

CQFD

A+

Watael · Le 21/12/2017, à 19:30

2)

man bash a écrit :

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.

un terminal X (xterm, rxvt, gnome-terminal, Konsole...) n'est pas un interpréteur de connexion (login shell).
3) normal ! un autre terminal est un autre processus.

JujuLand · Le 21/12/2017, à 19:36

Donc, c'est bien ce que je dis, même si mon explication est moins technique: lors de l'ouverture d'un terminal, comme on l'ouvre habituellement, sans --login, çà ne va pas chercher les divers fichiers profile.

A+

Watael · Le 21/12/2017, à 19:46

même ~/.bashrc n'est pas lu dans toutes les circonstances :
il est lu et exécuté lors de l'ouverture d'un terminal X, mais
il n'est pas lu, ni exécuté (!) lors de l'ouverture d'un interpréteur de connexion.
pour ce faire, il doit être sourcé dans un fichier profile.

JujuLand · Le 22/12/2017, à 00:24

Tu racontes n'importe quoi ici, et tu demandes le [Résolu] sur un post que j'avais semble-t-il déjà mis résolu.

T'as fumé ou t'as abusé de l’absinthe ?

A+

Edit : ce message répondait à un message de jack qui a été supprimé par son auteur.

Dernière modification par cqfd93 (Le 22/12/2017, à 20:14)

Ayral · Le 22/12/2017, à 00:49

Modération : @jack. Essaie quand même de faire attention à ce que tu racontes. Ou tu te trompes de discussion, ou alors je sais pas. Tu es parfois lourd.

Dernière modification par Ayral (Le 22/12/2017, à 11:45)

jack · Le 22/12/2017, à 09:31

Ayral a écrit :

Modération : @jack. Essaie quand même de faire attention à ce que tu racontes. Ou tu te trompes de discussion, ou alors je sais pas. Tu es parfois lourd.

Je me suis trompé de discussion toute mes excuses

Dernière modification par Ayral (Le 22/12/2017, à 11:46)

JujuLand · Le 22/12/2017, à 20:10

De plus, pour les lecteurs, il serait bien que tu fasses un petit effort, et que tu parles un peu mieux le français.

Ta dernière réponse prouve que tu es capable de parler autrement que sms ou javanais.

A+

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 20/12/2017, à 15:10

[Résolu] Execution d'un script depuis .profile

#2 Le 20/12/2017, à 15:28

Re : [Résolu] Execution d'un script depuis .profile

#3 Le 20/12/2017, à 15:32

Re : [Résolu] Execution d'un script depuis .profile

#4 Le 20/12/2017, à 16:32

Re : [Résolu] Execution d'un script depuis .profile

#5 Le 20/12/2017, à 16:40

Re : [Résolu] Execution d'un script depuis .profile

#6 Le 20/12/2017, à 16:53

Re : [Résolu] Execution d'un script depuis .profile

#7 Le 20/12/2017, à 17:25

Re : [Résolu] Execution d'un script depuis .profile

#8 Le 20/12/2017, à 17:45

Re : [Résolu] Execution d'un script depuis .profile

#9 Le 20/12/2017, à 20:31

Re : [Résolu] Execution d'un script depuis .profile

#10 Le 20/12/2017, à 20:42

Re : [Résolu] Execution d'un script depuis .profile

#11 Le 20/12/2017, à 20:56

Re : [Résolu] Execution d'un script depuis .profile

#12 Le 20/12/2017, à 22:00

Re : [Résolu] Execution d'un script depuis .profile

#13 Le 21/12/2017, à 11:40

Re : [Résolu] Execution d'un script depuis .profile

#14 Le 21/12/2017, à 12:15

Re : [Résolu] Execution d'un script depuis .profile

#15 Le 21/12/2017, à 12:30

Re : [Résolu] Execution d'un script depuis .profile

#16 Le 21/12/2017, à 12:50

Re : [Résolu] Execution d'un script depuis .profile

#17 Le 21/12/2017, à 15:28

Re : [Résolu] Execution d'un script depuis .profile

#18 Le 21/12/2017, à 16:22

Re : [Résolu] Execution d'un script depuis .profile

#19 Le 21/12/2017, à 19:30

Re : [Résolu] Execution d'un script depuis .profile

#20 Le 21/12/2017, à 19:36

Re : [Résolu] Execution d'un script depuis .profile

#21 Le 21/12/2017, à 19:46

Re : [Résolu] Execution d'un script depuis .profile

#22 Le 22/12/2017, à 00:24

Re : [Résolu] Execution d'un script depuis .profile

#23 Le 22/12/2017, à 00:49

Re : [Résolu] Execution d'un script depuis .profile

#24 Le 22/12/2017, à 09:31

Re : [Résolu] Execution d'un script depuis .profile

#25 Le 22/12/2017, à 20:10

Re : [Résolu] Execution d'un script depuis .profile

Pied de page des forums