Différent appel d'un script

Version imprimable

31/05/2013, 09h20
nymus7

Différent appel d'un script

Bonjour,

J'ai un script test.sh qui avait un mauvais chemin pour le shell :

Code:

#!/usr/bin/ksh

au lieu de

Code:

#!/bin/ksh

la commande which m'a permis de remédier à ce problème!

Mais!!! avec ce mauvais chemin, mon script ne fonctionnait pas si je l'appelais de cette façon :

Code:

/usr/local/sbin/test.sh

, logique! mais fonctionnait avec celle-ci :

Code:

. /usr/local/sbin/test.sh

Pardonnez ma question de débutant, mais pourquoi la deuxième manière fonctionnait? Quelqu'un pourrait-il m'en donner l'explication??
Merci et bonne journée
31/05/2013, 09h43
frp31

c'est pas fait pour lancer un script la forme

Code:

. /chemin/fichier

mais pour charger son contenu
le fait que si c'est un script il s'execute est "accessoire"

mais ducoup puisqu'on charge le contenu toute ligne valide est chargée... donc le contenu du script fonctionne (les commandes)

mais le ksh n'est pas lancé en début de script et ce dernier n'est donc pas executé en tant que script. (avec un shell ouvert spécifiquement pour lui)

par exemple la forme de charge

Code:

. ~/.profile

est sencé ne contenir que des variables mais rien n'empêche de lui faire lancer des commandes ....

pour résumer la différence c'est que tu exécutes des commandes dans un environnement connu et fixé avec shell quand l'entête est présente.
ou que tu les exécutes dans l'environnement tel qu'il est à un instant T avec toutes les consequences que tu peux immaginer.... si tu n'as pas l'entête correct

bref le fait que ton script fonctionne dans TON environnement malgré l'erreur est un coup de bol parce que le script est probablement simple et ne touche pas à des éléments trop dispersés ni citriques du système...ni ne fait appel à trop de fonctions et variables existantes.
31/05/2013, 10h26
jack-ft

je trouve pour le moins surprenant de mettre un script de test dans le répertoire "/usr/local/sbin"!
Il me semble que ce répertoire est réservé aux développeurs qui maîtrisent particulièrement bien unix... et, je ne sais pas pourquoi, mais j'ai des doutes...
Peux-tu nous dire pourquoi tu as mis ton script dans ce répertoire?

Citation:

Envoyé par nymus7

Quelqu'un pourrait-il m'en donner l'explication??

C'est la différence entre exécuter et sourcer.

Lorsqu'un script est exécuté par la commande le_script, le mécanisme interne de tous les unix consiste à regarder si la 1ère ligne contient un shebang (cf. wikipedia). Si c'est le cas, unix forke le process vers la commande désignée par ce shebang.
Si cette commande n'existe pas, il se produit une erreur, sinon il continue avec le reste du script passé à cette commande.

Lorsqu'un script est sourcé depuis un script ou depuis le shell du terminal, par . le_script, la ligne de shebang, si elle existe, est purement et simplement ignorée, comme n'importe quelle ligne de commentaire. Les instructions du script sont interprétées par le script ou le shell qui le source.

Pour bien voir la différence, tu peux faire l'essai suivant:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 cat > ./petit_test.sh <<EOF #!/bin/sh ma_variable=oui echo "ici ma_variable vaut '\${ma_variable}'" EOF chmod +x ./petit_test.sh unset ma_variable echo "ma_variable ne vaut rien: '${ma_variable}'" ./petit_test.sh echo "ma_variable ne vaut toujours rien: '${ma_variable}'" . ./petit_test.sh echo "et maintenant ma_variable vaut '${ma_variable}'"

:ccool: excellent message.

La différence entre sourcer ou exécuter entre sh et bash est ténue. Mais avec un fichier sed. C'est flagrant.

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
$ cat menudate.sed
#!/bin/sed -nf
 
/^<item>/,/<\/item>/{
 
        /^<title>/{
                s@<title>@@
                s@</title>@@
                h
        }
 
        /^<guid >/{
                s@<guid >@@
                s@</guid>@@
                H
        }
 
        /pubDate/{
                s@<pubDate>@@
                #s@.....@@
                s@</pubDate>@@
                #s@^\(......\).*@\1@
 
                H
                g
                s/\(.*\)\n\(.*\)\n\(.*\)/\3\t\1\n\2/
                p
        }
 
}
$ . menudate.sed
bash: item: Aucun fichier ou dossier de ce type
bash: title: Aucun fichier ou dossier de ce type
bash: title: Aucun fichier ou dossier de ce type
bash: /title: Aucun fichier ou dossier de ce type
bash: h : commande introuvable
bash: menudate.sed: line 9: Erreur de syntaxe près du symbole inattendu « } »
bash: menudate.sed: line 9: `    }'

05/06/2013, 09h27
nymus7

Merci beaucoup à tous pour vos réponses... :)

Citation:

Envoyé par jack-ft

je trouve pour le moins surprenant de mettre un script de test dans le répertoire "/usr/local/sbin"!
Il me semble que ce répertoire est réservé aux développeurs qui maîtrisent particulièrement bien unix... et, je ne sais pas pourquoi, mais j'ai des doutes...
Peux-tu nous dire pourquoi tu as mis ton script dans ce répertoire?

@jack-ft : j'ai toujours mis mes scripts sous "/usr/local/sbin", même ceux de tests... à vrai dire je ne me suis jamais posé la question pourquoi!
Que me conseillerais-tu?
05/06/2013, 10h41
N_BaH

Bonjour,

Citation:

Envoyé par nymmus7

j'ai toujours mis mes scripts sous "/usr/local/sbin", même ceux de tests... à vrai dire je ne me suis jamais posé la question pourquoi!
Que me conseillerais-tu?

sûrement pas /usr/local/sbin :

Citation:

Envoyé par man hier

/usr/local/sbin
Programmes d'administration installés localement.

à la rigueur, /usr/local/bin si les programmes doivent être accessibles par d'autres utilisateurs, sinon $HOME/bin