bonjour a tous!
 
je suis plutot nul en scripts shell alors je m'adresse à vous.
 
Est-il possible de passer une valeur d'un script 1 à un script 2 ??
mis à part le fait d'ecrire cette valeur depuis Script 1 dans un fichier texte qui sera lue par Script 2, existe-t-il d'autres solutions ?
 
merci a ceux qui me ré[#0055aa]pondront

à ma connaissance : code de retour ou variable d'environnement

une variable d'environnement,  c'est un peu comme une variable globale ??
 
peux-tu m'en dire plus ?
et merci au fait

soit tu la passes en paramètres su script 2,
soit tu fais un EXPORT VARIABLE=VALEUR
 
et $VARIABLE dans le script 2 pour récupérer la valeur

super !
je vais essayer ça  
 
merci pour ton aide jupiler (ainsi que minusplus)

[edit]--Message édité par Bolino--[/edit]

Il y a plus simple, tu fais passer les vairables comme paramêtres.
Dans le script 1, ca donne ceci (code entre les ---------- ) :
------------------
script2 $var1 $var2 $var3
------------------
Dans le script 2, tu lis les paramêtres sont accéssibles sous le nom :
$1 $2 $3
Il y a aussi $0 pour le nom du script , $* et deux trois autres dont je me rapelle plus à quoi elles servent (je vérait peut être ce soir si j'ai le temps).
Tu peux me croire, j'ai eu loccasion de faire un mini référenceur de présence de site (en gros, à partir de l'analyse des droits d'accés à certains répertoires, je créais automatiquement des pages html contenant les liens vers tous les sites réputé ouvert.) sur un serveur unix en script bash et un grand nombre de valeur était passé ainsi.
 
Si tu veux en savoir un peu plus sur ce script, écrit moi.
PS: pendant 1 an et demis j'avais le meilleur référenceur de l'IUT (aucune erreur de détection pendant plus de 15 mois de fonctionnement). Tout mes concurents de l'IUT (qui  ont essayé de faire aussi bien) avaient des liens cassés et/ou manquant. Après ayant obtenus mon DUT (en deux ans), il a été suprimé du serveur.

merci bien !
cette solution me parait attrayante ..
en fait mon script2 peut être appelé par 2 ou 3 scripts1 différents (pour rester dans la logique).
et selon le script1 qui appelle, le script2 effectuera un traitement différent.. voila pour la petite histoire
 
merci pour vos aides, j'y vois beaucoup plus clair maintenant

Pour compléter ce que disait omega2 :  
 
$0 : le nom du script
$1,$2,$3,...: les paramètres n° 1,2,... passés au script
$* : l'ensemble des paramètres passés au script, sous la forme d'un seul argument
$@ : l'ensemble des paramètres passés au script, un argument par paramètre
$# : le nombre de paramètres passés au script
$? : le code retour de la dernière commande
$$ : le PID du shell qui exécute le script
$! : le PID du dernier processus lancé en arrière-plan
 
(c'est dingue ce que l'on trouve dans un bouquin )

Oui et non: Omega ne repond pas a la question initiale: Il appelle le script 2 dans le script 1. Et effectivement, en ce cas, les variables locales au script 1 sont accessibles au script 2.
Sinon, c'est par des variables globales (au shell) qu'il faut passer. Et la ligne script2 $var1 $var2 $var3  marchera pour le script2 appelle en dehors du script1.
 
Faites gaffe dans tout ca que selon que vous utilisez un c-shell ou un k-shell, la syntaxe des variables et des commandes change.
A+,

gilou > Je me plante peut_être mais en programmation shell, le fait d'appeller un script à partir d'un autre ne permet pas de partager les variables de l'un à l'autre (sans les passer en tant que paramêtre).
Evidemment, si c'est deux scripts lancé l'un après l'autre (et non pas l'un par l'autre), cette méthode ne marche pas.

Euh...
Il me semble bien que si:
Si tu appelles le script shell script2 dans le scrpit1, il me semble bien que les varables locales au script1 sont connues dans l'environnement du script2.
A+,

 
Je pense qu'omega2 a raison, pour que les variables non exportées (en sh, locales pour csh) soient visibles dans le second script, il faut utiliser source
 
source script2 var1 ...

source, c'est du c-shell, un truc que j'evite comme la peste.
 
En ksh, on peut proceder ainsi:
si tu veux appeller le script2 dans le script1, avec la variable $TOTO dont la valeur sera passe a l'environnement du script2, on precede ainsi: sur la meme ligne, dans script1, on tape:
TOTO=$TOTO script2
 
une seconde methode (meilleure a mon avis) est la suivante:  
pour toute variable que tu veux passer a ton script, tu utilises la commande typeset -x (qui indique que la variable sera exportee dans l'environnement des commandes executees par le script, et en particulier, un autre script)
Dans l'exemple precedent, ca deviendrait (dans script1):
typeset -x TOTO
..... ici plein de lignes ou tu fais ce que tu veux, en particulier, tu peux modifier la valeur de $TOTO .....
script2
 
A+,

 
tcsh en interactif c'est pas si mal que ça, mais tu as raison, pour faire des scripts, mieux vaut prendre autre chose...
 
"source" est une commande commune au csh et au bash, mais effectivement elle n'existe pas dans le ksh . cette commande a l'avantage de ne pas créer de nouveau processus pour lancer la commande (c'est le même shell qui exécute la commande) et donc tout est partagé : la commande lancée dans source a accès à toutes les variable du script qui le lance (export ou pas), si la commande dans le source modifie ou crée une variable, celle-ci sera accessible dans le premier script avec sa nouvelle valeur etc.
 
exemple:
 
script1:
----------
#! /bin/bash
a=10
echo $0: a vaut $a
source script2 100
echo $0: a vaut $a
echo $0 et en plus il y a b qui vaut $b
# ...
 
script 2:
----------
#! /bin/bash
echo $0 "(s2)": début
a=50
b=$1
echo $0 "(s2)": fin
# ...
 
ça donne :
 
script1: a vaut 10
script1 (s2): début
script1 (s2): fin
script1: a vaut 50
script1: et en plus il y a b qui vaut 100

Certes, mais procedant ainsi, tu as un effet de bord, ce qui est normal puisque tes scripts partagent le meme environnement.
Si effectivement un effet de bord n'est pas genant pour le script appelant, c'est efficace, en particulier pour recuperer des variables positionnees par le second script.
Mais si tu ne veux pas d'effet de bord dans le script initial, il faut une methode du type de celle que j'exposais.
 
>tcsh en interactif c'est pas si mal que ça
Ben disons que le mode d'edition emacs en ksh est tellement pratique que c'est pour moi une raison suffisante. Et ksh (ou ses derives), en mode interactif, c'est tres pratique aussi.
Honnetement, j'ai jamais pu encaisser les !! et autre commandes biscornues pour editer l'historique, je preferre ^P
Mais c'est essentiellement une question de gout.
A+,