J'ai un script "cron_day_pierre" qui sauvegarde automatiquement de mes
données sur des disques montés.
Il fonctionnait très bien sur RH 7.2.
Sous debian il répond systématiquement :
bash: ./cron_day_pierre: cannot execute binary file
J'ai changé les droits plusieurs fois, rien à faire..
Même lorsque je me log en root.
IL me semble que j'ai eu le même message lorsque j'ai essayé d'exécuter des
binaires d'installation de JAVA.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
no_spam
On Sat, 10 Jul 2004 13:49:51 +0200, pierre wrote:
J'ai un script "cron_day_pierre" qui sauvegarde automatiquement de mes données sur des disques montés. Il fonctionnait très bien sur RH 7.2. Sous debian il répond systématiquement : bash: ./cron_day_pierre: cannot execute binary file
J'ai changé les droits plusieurs fois, rien à faire.. Même lorsque je me log en root.
Est-ce que la première ligne est bien: #!/bin/sh Est ce que ça marche quand il est lancé avec: sh -c ./cron_day_pierre ?
On Sat, 10 Jul 2004 13:49:51 +0200, pierre wrote:
J'ai un script "cron_day_pierre" qui sauvegarde automatiquement de mes
données sur des disques montés.
Il fonctionnait très bien sur RH 7.2.
Sous debian il répond systématiquement :
bash: ./cron_day_pierre: cannot execute binary file
J'ai changé les droits plusieurs fois, rien à faire..
Même lorsque je me log en root.
Est-ce que la première ligne est bien:
#!/bin/sh
Est ce que ça marche quand il est lancé avec:
sh -c ./cron_day_pierre
?
J'ai un script "cron_day_pierre" qui sauvegarde automatiquement de mes données sur des disques montés. Il fonctionnait très bien sur RH 7.2. Sous debian il répond systématiquement : bash: ./cron_day_pierre: cannot execute binary file
J'ai changé les droits plusieurs fois, rien à faire.. Même lorsque je me log en root.
Est-ce que la première ligne est bien: #!/bin/sh Est ce que ça marche quand il est lancé avec: sh -c ./cron_day_pierre ?
pierre
Est-ce que la première ligne est bien: #!/bin/sh Est ce que ça marche quand il est lancé avec: sh -c ./cron_day_pierre
C'est parfait merci beaucoup... J'ai fait un "man sh" mais ça ne m'a pas vaimenat expliqué le rôle de ces deux instructions... Pourquoi sont elles nécessaire sous debian pas sou Red Hat?
Encore une fois merci.
Est-ce que la première ligne est bien:
#!/bin/sh
Est ce que ça marche quand il est lancé avec:
sh -c ./cron_day_pierre
C'est parfait merci beaucoup...
J'ai fait un "man sh" mais ça ne m'a pas vaimenat expliqué le rôle de ces
deux instructions...
Pourquoi sont elles nécessaire sous debian pas sou Red Hat?
Est-ce que la première ligne est bien: #!/bin/sh Est ce que ça marche quand il est lancé avec: sh -c ./cron_day_pierre
C'est parfait merci beaucoup... J'ai fait un "man sh" mais ça ne m'a pas vaimenat expliqué le rôle de ces deux instructions... Pourquoi sont elles nécessaire sous debian pas sou Red Hat?
Encore une fois merci.
Michel Tatoute
Est-ce que la première ligne est bien: #!/bin/sh Est ce que ça marche quand il est lancé avec: sh -c ./cron_day_pierre
C'est parfait merci beaucoup... J'ai fait un "man sh" mais ça ne m'a pas vaimenat expliqué le rôle de ces deux instructions... Pourquoi sont elles nécessaire sous debian pas sou Red Hat?
Encore une fois merci.
la raison de la difference je ne sais, mais visiblement ta config de kernel ne reconnais pas ton cron_day_pierre comme un script shell.
#!/bin/sh
en debut de fichier tend à faire reconnaitre le fichier comme un script /bin.sh (c'est à dire shell).
de plus le sh -c lance directement le shell dessus... et la c'est imparable.
En fait je souçonne ton cript de faire reference à un progm de script inexistant ou place ailleurs.
Il commence par quoi ce cron_day_pierre?
Michel.
Est-ce que la première ligne est bien:
#!/bin/sh
Est ce que ça marche quand il est lancé avec:
sh -c ./cron_day_pierre
C'est parfait merci beaucoup...
J'ai fait un "man sh" mais ça ne m'a pas vaimenat expliqué le rôle de ces
deux instructions...
Pourquoi sont elles nécessaire sous debian pas sou Red Hat?
Encore une fois merci.
la raison de la difference je ne sais, mais visiblement ta config de
kernel ne reconnais pas ton cron_day_pierre comme un script shell.
#!/bin/sh
en debut de fichier tend à faire reconnaitre le fichier comme un script
/bin.sh (c'est à dire shell).
de plus le sh -c lance directement le shell dessus... et la c'est
imparable.
En fait je souçonne ton cript de faire reference à un progm de script
inexistant ou place ailleurs.
Est-ce que la première ligne est bien: #!/bin/sh Est ce que ça marche quand il est lancé avec: sh -c ./cron_day_pierre
C'est parfait merci beaucoup... J'ai fait un "man sh" mais ça ne m'a pas vaimenat expliqué le rôle de ces deux instructions... Pourquoi sont elles nécessaire sous debian pas sou Red Hat?
Encore une fois merci.
la raison de la difference je ne sais, mais visiblement ta config de kernel ne reconnais pas ton cron_day_pierre comme un script shell.
#!/bin/sh
en debut de fichier tend à faire reconnaitre le fichier comme un script /bin.sh (c'est à dire shell).
de plus le sh -c lance directement le shell dessus... et la c'est imparable.
En fait je souçonne ton cript de faire reference à un progm de script inexistant ou place ailleurs.
Il commence par quoi ce cron_day_pierre?
Michel.
Nicolas George
Michel Tatoute wrote in message :
de plus le sh -c lance directement le shell dessus... et la c'est imparable.
Non, c'est « sh script » qui demande d'exécuter le fichier comme un script. sh -c commande demande à sh d'exécuter commande comme si elle avait été tapée à l'invite. Normalement, ./script et sh -c ./script devraient faire la même chose. La différence constatée peut venir de deux choses : une erreur de manipulation au départ (comme l'absence du ./, j'ai la flemme de remonter dans le thread pour vérifier) ou bien une différence de comportement entre le shell interactif et sh.
Michel Tatoute wrote in message
<pan.2004.07.10.17.05.28.565884@alussinan.org>:
de plus le sh -c lance directement le shell dessus... et la c'est
imparable.
Non, c'est « sh script » qui demande d'exécuter le fichier comme un
script. sh -c commande demande à sh d'exécuter commande comme si elle
avait été tapée à l'invite. Normalement, ./script et sh -c ./script
devraient faire la même chose. La différence constatée peut venir de
deux choses : une erreur de manipulation au départ (comme l'absence du
./, j'ai la flemme de remonter dans le thread pour vérifier) ou bien une
différence de comportement entre le shell interactif et sh.
de plus le sh -c lance directement le shell dessus... et la c'est imparable.
Non, c'est « sh script » qui demande d'exécuter le fichier comme un script. sh -c commande demande à sh d'exécuter commande comme si elle avait été tapée à l'invite. Normalement, ./script et sh -c ./script devraient faire la même chose. La différence constatée peut venir de deux choses : une erreur de manipulation au départ (comme l'absence du ./, j'ai la flemme de remonter dans le thread pour vérifier) ou bien une différence de comportement entre le shell interactif et sh.
Michel Tatoute
Michel Tatoute wrote in message :
de plus le sh -c lance directement le shell dessus... et la c'est imparable.
Non, c'est « sh script » qui demande d'exécuter le fichier comme un script. sh -c commande demande à sh d'exécuter commande comme si elle avait été tapée à l'invite. Normalement, ./script et sh -c ./script devraient faire la même chose. La différence constatée peut venir de deux choses : une erreur de manipulation au départ (comme l'absence du ./, j'ai la flemme de remonter dans le thread pour vérifier) ou bien une différence de comportement entre le shell interactif et sh.
Ben ca! t'as raison!
je m'incline! ;-)
Michel.
Michel Tatoute wrote in message
<pan.2004.07.10.17.05.28.565884@alussinan.org>:
de plus le sh -c lance directement le shell dessus... et la c'est
imparable.
Non, c'est « sh script » qui demande d'exécuter le fichier comme un
script. sh -c commande demande à sh d'exécuter commande comme si elle
avait été tapée à l'invite. Normalement, ./script et sh -c ./script
devraient faire la même chose. La différence constatée peut venir de
deux choses : une erreur de manipulation au départ (comme l'absence du
./, j'ai la flemme de remonter dans le thread pour vérifier) ou bien une
différence de comportement entre le shell interactif et sh.
de plus le sh -c lance directement le shell dessus... et la c'est imparable.
Non, c'est « sh script » qui demande d'exécuter le fichier comme un script. sh -c commande demande à sh d'exécuter commande comme si elle avait été tapée à l'invite. Normalement, ./script et sh -c ./script devraient faire la même chose. La différence constatée peut venir de deux choses : une erreur de manipulation au départ (comme l'absence du ./, j'ai la flemme de remonter dans le thread pour vérifier) ou bien une différence de comportement entre le shell interactif et sh.
Ben ca! t'as raison!
je m'incline! ;-)
Michel.
no_spam
On Sat, 10 Jul 2004 16:05:21 +0200, pierre wrote:
Est-ce que la première ligne est bien: #!/bin/sh Est ce que ça marche quand il est lancé avec: sh -c ./cron_day_pierre
C'est parfait merci beaucoup... J'ai fait un "man sh" mais ça ne m'a pas vaimenat expliqué le rôle de ces deux instructions... Pourquoi sont elles nécessaire sous debian pas sou Red Hat?
Je ne sais pas. Ca ne devrait pas marcher non plus sous RedHat, en toute logique, d'après les specs Unix. Ce qui est sur, par contre, c'est que quand un fichier executable commence par #!<xxx> le noyau comprends qu'il faut utiliser la commande <xxx> pour executer le fichier en question. Ainsi, les scripts shell doivent commencer par #!/bin/sh ou #!/bin/bash ou zsh, ... les scripts perl par: #!/usr/bin/perl etc... Comme ça, ces fichiers sont executés exactement de la même façon que les executables binaires, du moins du point de vue utilisateur.
On Sat, 10 Jul 2004 16:05:21 +0200, pierre wrote:
Est-ce que la première ligne est bien:
#!/bin/sh
Est ce que ça marche quand il est lancé avec:
sh -c ./cron_day_pierre
C'est parfait merci beaucoup...
J'ai fait un "man sh" mais ça ne m'a pas vaimenat expliqué le rôle de ces
deux instructions...
Pourquoi sont elles nécessaire sous debian pas sou Red Hat?
Je ne sais pas. Ca ne devrait pas marcher non plus sous RedHat,
en toute logique, d'après les specs Unix.
Ce qui est sur, par contre, c'est que quand un fichier executable
commence par
#!<xxx>
le noyau comprends qu'il faut utiliser la commande <xxx> pour
executer le fichier en question.
Ainsi, les scripts shell doivent commencer par
#!/bin/sh
ou
#!/bin/bash ou zsh, ...
les scripts perl par:
#!/usr/bin/perl
etc...
Comme ça, ces fichiers sont executés exactement de la même façon
que les executables binaires, du moins du point de vue utilisateur.
Est-ce que la première ligne est bien: #!/bin/sh Est ce que ça marche quand il est lancé avec: sh -c ./cron_day_pierre
C'est parfait merci beaucoup... J'ai fait un "man sh" mais ça ne m'a pas vaimenat expliqué le rôle de ces deux instructions... Pourquoi sont elles nécessaire sous debian pas sou Red Hat?
Je ne sais pas. Ca ne devrait pas marcher non plus sous RedHat, en toute logique, d'après les specs Unix. Ce qui est sur, par contre, c'est que quand un fichier executable commence par #!<xxx> le noyau comprends qu'il faut utiliser la commande <xxx> pour executer le fichier en question. Ainsi, les scripts shell doivent commencer par #!/bin/sh ou #!/bin/bash ou zsh, ... les scripts perl par: #!/usr/bin/perl etc... Comme ça, ces fichiers sont executés exactement de la même façon que les executables binaires, du moins du point de vue utilisateur.
