erreur d'exécution d'un script shell

erreur d'exécution d'un script shell - Codes et scripts - Linux et OS Alternatifs

Marsh Posté le 30-12-2004 à 21:07:40    


salut,
 
tout d'abord, je note que je travaille sous le noyau 2.6.8
 
en fait, j'ai crée un script shell qui :
  - charge des modules noyau via la commande "insmod module.ko"
  - exécute un programme ("./test" ) qui utilise ces modules
 
le probléme est que lors de l'exécution de mon script ("./run" ), l'erreur ":bad interpreter" m'est affichée!! :??:  
je ne sais c où le problème?
 
merci pour toutes réponses
 

Reply

Marsh Posté le 30-12-2004 à 21:07:40   

Reply

Marsh Posté le 30-12-2004 à 21:13:46    

en haut de ton script tu utilise quel interpréteur
normalement la premiere ligne de ton script doit etre du style #!/chemin/vers/ton/interpreteur


---------------
Dommage :-) | chess games
Reply

Marsh Posté le 30-12-2004 à 22:58:27    

j'utilise #!bin/sh

Reply

Marsh Posté le 30-12-2004 à 23:30:57    

#!/bin/sh
  ^
manque un / ici

Reply

Marsh Posté le 30-12-2004 à 23:32:42    

matafan a écrit :

#!/bin/sh
  ^
manque un / ici



 
?

Reply

Marsh Posté le 30-12-2004 à 23:53:44    

Eh ben c'est dur pour un / manquant... Il a ecrit "#!bin/sh" au lieu de "#!/bin/sh".

Reply

Marsh Posté le 30-12-2004 à 23:56:47    

Excuses, j'ai regardé ce que tu avais écrit et non ce que brahimos avait écrit :o . Vais me coucher...

Reply

Marsh Posté le 31-12-2004 à 00:27:11    

tu suggère que c'est une erreur de syntaxe!
est ce que un interpréteur sh ou bash ou autre définie sa propre syntaxe?
 
et merci

Reply

Marsh Posté le 31-12-2004 à 00:39:58    

merci pour la correction;
une autre question:
si j'omet de mettre #!/bin/sh en haut du script, ca marche est ce qu'il paraît!
est ce nécessaire de le mettre ?

Reply

Marsh Posté le 31-12-2004 à 01:33:22    

c'est fortement recommandé

Reply

Marsh Posté le 31-12-2004 à 01:33:22   

Reply

Marsh Posté le 31-12-2004 à 04:22:16    

Non, sans le #!/bin/sh ça ne marchera pas. Tu pourra toujours lancer ton script par "sh ./monscript" ou ". ./monscript", mais pas directement par "./monscript".
 
Edit : le #!/bin/sh, ça sert à dire au kernel que ce fichier est à executer par /bin/sh. Ce n'est pas spécifique à un shell en particulier. En fait le shell ne lit même pas cette ligne, qui n'est pour lui rien d'autre qu'un commentaire. Cette ligne est destinée au kernel.


Message édité par matafan le 31-12-2004 à 04:25:48
Reply

Marsh Posté le 31-12-2004 à 11:05:47    

par exemple, tu pourrai avoir un auter script qui commencerai par

#!/bin/gawk

ou

#!/usr/bin/perl

pour des scripts respectivement écrits en awk ou perl.
Cette ligne renseigne l'interpréteur à utiliser pour ton script !

Reply

Marsh Posté le 02-01-2005 à 17:05:23    


merci encore une fois pour vos conseils.
Mais voilà que je me confronte à une autre erreur lors de l'exécution de mon script.  
 
voila, un apercu du code du script :
 
#!/bin/sh
TMP=$PWD
.
.
cd $TMP      
./btest  
 
j'exécute mon script via "sh run"
 
et  le réultat de l'exécution et les erreurs affcihées:
 
: Aucun fichier ou répertoire de ce typeexemples/tests
run: line 15: ./btest: Aucun fichier ou répertoire de ce type

Reply

Marsh Posté le 02-01-2005 à 17:06:59    

chaque ligne s'effectue dans un fork() différent. Si tu veux faire ça il faut faire :
 

Code :
  1. cd $TMP && ./btest


---------------
uptime is for lousy system administrators what Viagra is for impotent people - mes unixeries - github me
Reply

Marsh Posté le 02-01-2005 à 17:14:29    

cad dans le meme process!
et si je met cd $TMP ; ./btest c la meme chose!

Reply

Marsh Posté le 02-01-2005 à 17:19:58    

normal [:spamafote]
 
lis la doc de bash et tu verras ce qui se passe de façon interne lors de l'éxécution d'un script


---------------
uptime is for lousy system administrators what Viagra is for impotent people - mes unixeries - github me
Reply

Marsh Posté le 02-01-2005 à 18:19:49    

j'ai un peu compris le principe d'exec interne d'une liste de commande mais l'erreur ici c'est que la commande " cd $TMP" n'est pas interprété correctement!
syntaxiquement c correct, donc saviez vous ce qui s'est passé?

Reply

Marsh Posté le 02-01-2005 à 18:50:10    

oui. je te l'ai expliqué plus haut.
 
cd $TMP est interprété correctement mais la commande suivante n'est pas éxécutée dans le même contexte (je simplifie pas tapay) donc le script est revenu là où il était avant.
 
ex :
 
tu es dans ~
tu fais ls
il liste ~ dans un un processus fils
le fils meure
tu fais cd $TMP
il se place dans $TMP pour le processus fils. Le fils meure. Le père est toujours dans ~
tu fais ./test
~/.test est éxécuté dans un fils (puisque la référence du père est ~)
 
compris ?


---------------
uptime is for lousy system administrators what Viagra is for impotent people - mes unixeries - github me
Reply

Marsh Posté le 02-01-2005 à 19:20:32    

black_lord, t'as fumée quoi :ouch: Le shell ne fork absolument pas un nouveau process pour chaque ligne !
 
brahimos montre ton script en entier, il doit y avoir une erreur quelque part.

Reply

Marsh Posté le 02-01-2005 à 19:21:50    

t'es sur ? là tu vois je suis sceptique... je vais relire le man de bash


---------------
uptime is for lousy system administrators what Viagra is for impotent people - mes unixeries - github me
Reply

Marsh Posté le 02-01-2005 à 19:27:21    

j'ai relu la source de bash : il forke.


---------------
uptime is for lousy system administrators what Viagra is for impotent people - mes unixeries - github me
Reply

Marsh Posté le 02-01-2005 à 19:34:05    

Ben relit mieux... cd n'est pas une commande, c'est un builtin du shell.
 

/home/nicolas/tmp% mkdir dir
/home/nicolas/tmp% echo toto > dir/toto
/home/nicolas/tmp% ls -lAR
.:
total 4
drwxr-xr-x  2 nicolas users 4096 Jan  2 12:31 dir
 
./dir:
total 4
-rw-r--r--  1 nicolas users 5 Jan  2 12:31 toto
/home/nicolas/tmp% cat <<EOF > test.sh
heredoc> #!/bin/sh
heredoc> pwd
heredoc> ls -Al
heredoc> cd dir
heredoc> pwd
heredoc> ls -Al
heredoc> EOF
/home/nicolas/tmp% chmod +x test.sh
/home/nicolas/tmp% ./test.sh
/home/nicolas/tmp
total 8
drwxr-xr-x  2 nicolas users 4096 Jan  2 12:31 dir
-rwxr-xr-x  1 nicolas users   39 Jan  2 12:32 test.sh
/home/nicolas/tmp/dir
total 4
-rw-r--r--  1 nicolas users 5 Jan  2 12:31 toto
/home/nicolas/tmp%

Reply

Marsh Posté le 02-01-2005 à 19:35:25    

j'ai pas dit que cd était une commande, j'ai dit qu'il forkait pour éxécuter des commandes
 
relis la source [:spamafote]
 
edit : écrit un shell, c'est instructif ;)


Message édité par black_lord le 02-01-2005 à 19:36:41

---------------
uptime is for lousy system administrators what Viagra is for impotent people - mes unixeries - github me
Reply

Marsh Posté le 02-01-2005 à 19:40:14    

Mais puta*n arrète d'affirmer n'importe quoi... Le shell ne fork absolument pas à chaque ligne. Les builtins (cd, for, echo...) sont exécutées par le shell qui interprète le script, à part évidemment si elles sont a droite d'un pipe.
 
Edit : écrit un shell ? C'est exactement ce que j'ai fais dans le post au dessus du tiens. Crois moi, je sais de quoi je parle...


Message édité par matafan le 02-01-2005 à 19:42:46
Reply

Marsh Posté le 02-01-2005 à 19:44:45    

je ne dis pas qu'il forke à chaque ligne :o Exécuter des commandes est différent de lancer un builtin hein [:dawa]
 
edit : tu as écris un script shell, pas un shell ;)


Message édité par black_lord le 02-01-2005 à 19:45:18

---------------
uptime is for lousy system administrators what Viagra is for impotent people - mes unixeries - github me
Reply

Marsh Posté le 02-01-2005 à 20:07:14    

black_lord a écrit :

je ne dis pas qu'il forke à chaque ligne :o


 
Ah bon ? J'avais cru lire "chaque ligne s'effectue dans un fork() différent".
 

black_lord a écrit :

Exécuter des commandes est différent de lancer un builtin hein [:dawa]


 
Ah ben donc on est d'accord, très bien. C'est marrant parce que là encore j'ai cru lire "il se place dans $TMP pour le processus fils. Le fils meure. Le père est toujours dans ~". Tu as dis qu'il faisait le chdir dans un processus fils, on est bien d'accord ? Moi je dis non, cd est un builtin et il n'y a pas de fork. Le chdir est fait dans le shell qui interprete ton script.
 

black_lord a écrit :

edit : tu as écris un script shell, pas un shell ;)


 
Ok j'ai mal compris ce que tu voulais dire. Cela dit, pour ta gouverne, j'ai écrit un mini shell en dernière année d'école d'ingé.


Message édité par matafan le 02-01-2005 à 20:07:52
Reply

Marsh Posté le 02-01-2005 à 20:49:09    

autant pour moi, j'ai aussi écrit un mini-shell et j'ai dit beaucoup de conneries :jap:
 
le shell ne forke (si je ne me plante pas [:dawa]) que pour les bg process et les pipes.


---------------
uptime is for lousy system administrators what Viagra is for impotent people - mes unixeries - github me
Reply

Marsh Posté le 03-01-2005 à 01:10:51    

c trés intéressant votre discussion même si je suis perdu quelques fois.
 
j'ai lu la man bash, et j'ai cru comprendre, comme matafan l'a dit, que le script s'exécute dans un seul process (ou fork).
 
bref, pour mon cas je ne comprends pas pourquoi ca marche pas la commande (ou builtin) :
 
cd $TMP
 
voila mon script qui sert à exécuter un prog c sous Linux/RTAI:
 
1 #!/bin/sh
2 TMP=$PWD
3 echo " "
4 cd /usr/realtime/modules/
5 insmod ./rtai_hal.ko
6 insmod ./rtai_tasklets.ko
7 cd $TMP
8 ./btest
 
à noter que lorsque je remplace la ligne 7 et 8 par  
 
cd ~/ && ./btest
ca marche.
 
en fait, quelle est la difference entre commande et buitin? est ce que buitin veut dire les focntions propre au shell (cd, echo,..)?


Message édité par brahimos le 03-01-2005 à 01:15:02
Reply

Marsh Posté le 03-01-2005 à 02:08:22    

Je parie un pot de nutella que le répertoire d'où tu lances le script à un espace dans son chemin :o  
 
Rajoute des guillemets (par exemple TMP="$PWD" ). C'est probablement le point qui pose le plus de problème en programmation bash...
 
Les builtins sont effectivement des fonctions intégrées dans le shell, par opposition à un executable classique. echo n'est pas builtin d'ailleurs. D'autres exemple de builtins (pour zsh) : foreach, run-help, ou print.

Reply

Marsh Posté le 03-01-2005 à 04:14:08    

echo est un builtin dans la plupart des shells, pour des raisons évidentes de performances.

/home/nicolas% ash -c "type echo"
echo is a shell builtin
/home/nicolas% bash -c "type echo"
echo is a shell builtin
/home/nicolas% zsh -c "type echo"
echo is a shell builtin


J'ai pas de ksh sous la main, mais c'est aussi un builtin en ksh.

Reply

Marsh Posté le 03-01-2005 à 10:13:33    

[citation=614375,0,29][nom]pillow a écrit[/nom]Je parie un pot de nutella que le répertoire d'où tu lances le script à un espace dans son chemin :o  
 
bain non, j'ai vérifier mais pas d'espace dans mon chemin

Reply

Marsh Posté le 03-01-2005 à 18:26:06    

Donne ton script complet.

Reply

Marsh Posté le 08-01-2005 à 21:05:40    

brahimos a écrit :

c trés intéressant votre discussion même si je suis perdu quelques fois.
 
j'ai lu la man bash, et j'ai cru comprendre, comme matafan l'a dit, que le script s'exécute dans un seul process (ou fork).
 
bref, pour mon cas je ne comprends pas pourquoi ca marche pas la commande (ou builtin) :
 
cd $TMP
 
voila mon script qui sert à exécuter un prog c sous Linux/RTAI:
 
1 #!/bin/sh
2 TMP=$PWD
3 echo " "
4 cd /usr/realtime/modules/
5 insmod ./rtai_hal.ko
6 insmod ./rtai_tasklets.ko
7 cd $TMP
8 ./btest
 
à noter que lorsque je remplace la ligne 7 et 8 par  
 
cd ~/ && ./btest
ca marche.
 
en fait, quelle est la difference entre commande et buitin? est ce que buitin veut dire les focntions propre au shell (cd, echo,..)?


 
 
$PWD n'a pas de valeur, donc $TMP non plus
 
ne voulais tu pas faire TMP=`pwd` ?

Reply

Marsh Posté le 09-01-2005 à 17:11:46    

$PWD contient le répertoire courant. On peut tout à fait faire TMP=$PWD.
 
Tu n'as pas besoin de changer de répertoire. Tu peux simplement faire insmod /usr/realtime/modules/rtai_hal.ko.

Reply

Marsh Posté le 12-01-2005 à 14:57:17    

En réalité, lorsque tu fais ./mon_script.sh, tu execute le script dans un autre processus shell. Du coup, la variable $PWD n'est pas modifié pour ton shell courant. Execute ton script grâce à source ./mon_script.sh et ça devrait passer :)

Reply

Marsh Posté le 12-01-2005 à 22:14:00    

Rien a voir. Il lance ./btest dans le script, pas en ligne de commande apres l'execution de son script. Son truc devrait marcher, point.
 
Ah tien je viens de remarques un truc : tu dis que ca marche avec "cd ~/ && ./btest", mais dans ton script tu as "cd $TMP". Est-ce que tu lances bien le script depuis ton home ?

Reply

Marsh Posté le    

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed