Discussion :

[nymus7]

Bonjour,

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

#!/usr/bin/ksh

au lieu de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

#!/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 :

Sélectionner tout - Visualiser dans une fenêtre à part

/usr/local/sbin/test.sh

, logique! mais fonctionnait avec celle-ci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

. /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

[frp31]

c'est pas fait pour lancer un script la forme

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

. /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 :

Sélectionner tout - Visualiser dans une fenêtre à part

. ~/.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.

[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]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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}'"

[Flodelarab]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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: `    }'

[nymus7]

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

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?

[N_BaH]

Bonjour,

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 :

/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