Bash Depuis un Bash ?

Support Debian
#1

Salut à tous !

S’il vous plait,
J’essaye de lancer un bash depuis un bash sur une Debian 6, mais je n’obtiens que des erreurs.
Sur un serveur virtuel cela fonctionne, mais par contre sur un serveur dedie cela ne veut pas fonctionner ; impossible d’arriver à faire exécuter le second fichier bash depuis le premier.

#!/bin/sh echo -e '\033[1;33;40m Bonjour !' read -p [[ "$REPLY" != [yYoO] ]] || bash hello.sh

Merci :wink:

#2

Je m’y connais pas mais, les fichier sh doivent s’exécuter via sh ./x.sh il me semble.

Donc: bash hello.sh devient sh hello.sh
Ou bash ./hello.sh
Ou sh ./hello.sh

Si sa fonctionne pas, je redis, je m’y connaissais pas :smiley:

Il y a une section de programmation, ils pourront mieux t’aider, mais sujet déjà ouvert donc le faire déplacer via un modérateur.

#3

Merci pour la réponse :wink:

J’ai déjà essayé cela, mais malheureusement cela ne semble pas plus fonctionner et je ne comprends pas le problème.

#4

En fait il sert à quoi ton script ? j’ai pas compris à quoi servira la dernière ligne.

#5

[quote=“debynoob”]Salut à tous !

S’il vous plait,
J’essaye de lancer un bash depuis un bash sur une Debian 6, mais je n’obtiens que des erreurs.
Sur un serveur virtuel cela fonctionne, mais par contre sur un serveur dedie cela ne veut pas fonctionner ; impossible d’arriver à faire exécuter le second fichier bash depuis le premier.

#!/bin/sh echo -e '\033[1;33;40m Bonjour !' read -p [[ "$REPLY" != [yYoO] ]] || bash hello.sh

Merci :wink:[/quote]
Pourquoi pas #!/bin/bash
Ensuite, je suppose que le prog ‘hello.sh’ est bien dans un dossier du PATH.
Ça n’a rien à voir avec le code mais je trouve bizarre que tu dises “bonjour” et que tu supposes qu’on pourrait te répondre ‘yes’ ou ‘oui’, ce que tu ne veux pas. :wink:

#6

Salut,
Tu souhaites bien lancer un script depuis un autre script, c’est ça?

Où est tu situé à l’exécution du script hello.sh?
Si tu n’es pas dans le même dossier, il ne s’exécutera jamais.
Y a t’il un retour à la commande, si oui peux-tu nous la donner?

Moi j’ai un script qui contient ceci:

SSHGATE_DIR_BIN='/usr/bin' [...] ${SSHGATE_DIR_BIN}/sshgate-sync
Et cela fonctionne.
(Je te conseille de rentrer le path complet du fichier plutôt que simplement le nom du script, pour être sûr…)

Dernière chose, est-ce que ton script hello.sh est rendu exécutable?
Si non:

#7

Merci pour vos réponses :wink:

C’est un script d’exemple de manière à simplifier le problème et ce dernier présente les mêmes caractéristiques d’erreur que je rencontre.

Le Serveur Dédié est opérationnel depuis plusieurs mois (le virtuel est un management géré sous une application Windows chez le même Hébergeur) mois toutefois je voulais améliorer certains scripts du Dédié. Vu que je ne suis pas un pro de Linux alors je me contentais du minimums :slightly_smiling: Donc je m’attendais plus à une réponse compliquée du genre de “devoir faire une mise à jour spéciale” :slightly_smiling:

Par rapport à vos remarques, c’est pour cela que je ne comprends pas, le fichier est simplement dans le même dossier donc pas de problème de Path, de Directory, ni même d’attribut de fichier, voire d’entete fichier, en plus ils ont tous la même Chmod.

J’obtiens un message du genre :
: Aucun fichier ou dossier de ce type

J’ai essayé de forcer le path, d’utiliser sh, bash, ./ c’est pour cela que cela me rend un peu chèvre :slightly_smiling:

J’ai même pris la peine de revérifier le Chown :astonished:

Moi qui pensait que sur une même version de Linux (même si une est hostée virtuelle) il n’y avait pas de différences pour des choses de base, alors je ne comprends pas pourquoi. J’ai un problème quelque part, mais la question est de savoir où ? voire surtout pourquoi ?
Le pire est que le problème est sur le “Dédié version Serveur console” et non pas sur le “Serveur virtuel version Serveur console”.

Merci :wink:

#8

C’est peut-être une erreur qui est dans hello.sh ?

#9

[quote]: Aucun fichier ou dossier de ce type[/quote]Ce genre de réponse est lié à une adresse mal fournie, en principe.
Au lieu de , mets le chemin complet <bash /home/moi/dossier/hello.sh>
ou, à la rigueur, <bash ./hello.sh>

#10

Merci pour vos réponses :wink: mais on trouve les mêmes éléments dans les réponses précédentes :slightly_smiling:
Ayant déjà aussi évoqué PATH & Co.

J’ai même utilisé à l’identique les fichiers utilisés sur le serveur virtuel. J’ai même fait des manipulation pour vérifier qu’il n’y avait pas un problème de “codage des caractères” dans les fichiers.

Un jour peut-être trouverais-je l’origine de ce “bug”. Mais pour l’heure c’est dingue autant que perturbant, parce que cela devrait fonctionner. Un paquet doit certainement avoir causé cela…

Bon je crois que pour l’heure il n’y a pas de solution, merci pour votre aide :slightly_smiling:

Y-a-t’il un moyen de vérifier ou de mettre à jour les paquets qui peuvent être liés au système de fichiers BASH ?

Merci :wink:

#11

Je penses pas qu’il est lier à la version du bash.
Je m’y connais pas trop mais, je vois pas pourquoi il y a aurais une différence entre un linux installer normalement et virtualisé, les deux fonctionnent de même manière.

Il serait préférable de mettre le sujet côté programmation, mais de l’autre côté si c’est lié à un autre problème venant du système je sais pas.

#12 

+1
Ca ne devrait rien changer du tout...

+1
Ca ne devrait rien changer du tout…

#13

Bonjour,

Même si en 2012, je compte avoir de supers pouvoirs, je n’ai toujours pas celui de divination. Ton premier message manque sincèrement d’informations.

Voici quelques questions qui pourraient nous aider.
Comment la copie a été faite ? Est-ce un copier/coller d’une fenêtre à l’autre ?
Les clés MD5 des deux scripts sont-elles identiques entre les serveurs ?
Quand tu fais un “cat -ev TON_SCRIPT”, as-tu des “$” ou des “^M” en fin de ligne ?
Que font un “type sh” et “type bash” ?
Que te donnent un “file hello.sh” et “file ton_lanceur_de_hello.sh” ?
Que te donnent un “stat hello.sh” et “stat ton_lanceur_de_hello.sh” ?
Que donne un “/hello.sh” ?

LeDub script enquêteur :wink:

#14

en supposent que les script sont dans le même répertoire.
script appellent

#!/bin/sh echo 'Bonjour !' sh hello.sh 2 # passe 2 a la varriable $1 du script appeler echo $? # affiche la valeur retour du script

scripte hello.sh

#!/bin/sh echo "execution script hello.sh" if [ $1 -eq 1 ];then return 10 else return 20 fi

note pour les droits tous dépend comment on appel le script.
si on utilise quelque chose du genre:

les droit en lecture suffise car c’est sh qui est exécuter avec pour paramètre le fichier texte contenant le code.
par contre si on utilise :

ou

il faut les droit en lecture et en exécution et ne pas oublier #!/chemin/vers/interpréteur en générale /bin/sh ou /bin/bash en premier ligne du scripte.

#15

Sur Squeeze, /bin/sh n’est pas bash, mais dash, et j’ai déjà rencontré des problèmes de test ( je crois ) en ayant utilisé la syntaxe bash avec sh, plus restreint et plus léger car POSIX_ly correct.

Il faut mieux utiliser “/bin/bash /usr/local/bin/hello.sh”, c’est à dire des noms avec l’adresse complète ( absolue )

Mais pourquoi ne pas utiliser /usr/local/bin/hello.sh directement ?
Si le problème se pose, ($hello.sh par exemple) ne serait-ce pas plutôt eval qui doit être utilisé?

#16

Merci à tous pour vos réponses et votre soutien :slightly_smiling:

Merci tout particulièrement à LeDub qui a visé juste parce que cela m’a aidé à revoir ma copie avec une autre approche :slightly_smiling:
J’essaye d’apprendre de mes erreurs c’est comme cela que l’on progresse

J’espère que cela en aidera d’autres qui pourraient avoir des surprises du même genre :slightly_smiling:

Ce qui m’a induit en erreur ce sont 2 choses :

  • déjà à cause d’une autre commande read –p
  • ensuite les fins de ligne ^M$
  • une réaction surprenante des scripts avec une certaine interaction des 2 facteurs précédents.

Quand on a ^M$ en fin de ligne ($0D$0A) read –p fonctionne “sans argument” mais cela empêche le script d’appeler un autre script ; par contre curieusement le reste du script fonctionne :astonished: et ce y compris avec plusieurs tests $REPLY les uns derrière les autres :astonished:

Si on a $ en fin de ligne ($0A) et bien read –p refuse de fonctionner parce que ce dernier demande d’ajouter un argument qu’il affiche comme prompt en début de ligne.

Curieusement sur la version Virtuelle la gestion du script était plus exigeante et m’avait fait ajouter un argument au read –p >>> read –p ! et on a alors un prompt ! en début de ligne.
Ce qui veut dire que si on ne prête pas attention en pensant que c’est une simple erreur de formatage du texte, hé bien on se retrouve avec quelque chose de bizarre qui peut fonctionner sur 3 pattes. Ou comment un truc “simple” se transforme en soucis.

Pour moi cette gestion différente des fins de lignes entre Windows et Linux doit parfois occasionner de nombreux problèmes sur pas mal de serveurs si l’on est, soit pas suffisamment attentif, soit pas suffisamment expérimenté concernant la connaissance de certaines commandes. Et comme je suis bien loin d’en savoir autant que j’aimerai… alors :slightly_smiling:

Encore une fois merci à tous :wink:

#17

Salut,

Ce post était intéressant, je plussois même si je le dirais autrement :

Ensuite je n’aurai pas pensé à ce pb, alors que je le connais bien ( quel naze … )

Bien vu LeDub

Comme josephtux l’a dit je ne vois pas l’intérêt d’un bash hello.sh alors q’un simple /chemin/vers/hello.sh est suffisant, je dirais même que c’est du gâchis de mémoire, mais il faut bien apprendre ! :stuck_out_tongue:

En ligne de cde, pour convertir des fichier DOS vers Unix, tu peux directement faire ceci :

sed -e 's/^M$//' nom_de_ton_fichier_DOS > nom_de_ton_fic_convertis_Unix

pour obtenir le “^M” il faut saisir “Control-V Control-M”, ce qui veut dire qu’un strict copier-coller de cette ligne de cde ne fonctionnera pas …

Pour faire l’inverse (Unix to DOS) :

sed -e 's/$/^M/' nom_de_ton_fichier_Unix > nom_de_ton_fic_convertis_DOS

En prime, parce que c’est la nouvelle année, et que le citrate de betaïne fait effet :mrgreen: :033 :005 , voici un petit script que je viens de faire, qui ne le fait que de DOS ver Unix, une petite option supplémentaire te permettra facilement d’utiliser le même script dans les 2 sens (même si perso je préfère le sed en ligne de cde, c + simple) :
[size=85][code]cat ~/bin/dos_2_unix.sh

#! /bin/sh

Description : suppression du caractère spécial 0x0D ( \r retour chariot ) qui sous DOS

précède le traditionnel 0x0A ( \n fin de ligne )

pour saisir ^M il faut saisir Ctrl-V Ctrl-M

if [ “$#” -lt “2” ] ; then
echo “Usage : $0 nom_de_fichier_DOS nom_du_fichier_converti”
exit 1
fi

if [ ! -e “$1” ] ; then
echo “Le fichier $1 n’existe pas”
exit 2
fi

if [ -e “$2” ] ; then
echo “Le fichier $2 destiné à accuellir la conversion existe déjà ! Abandon de la conversion”
exit 3
fi

pour saisir ^M il faut saisir Ctrl-V Ctrl-M

sed -e ‘s/^M$//’ “$1” > “$2”

echo “Conversion de $1 de format DOS vers $2 de format Unix terminée”

###################################
[/code][/size]
Attention, un strict copier/coller de ce script ne fonctionnera pas à cause de la ligne

sed -e 's/^M$//' "$1" > "$2"

Il faudra que tu édites spécifiquement cette ligne pour remplacer le “^M” par “Crtl-V Ctrl-M” ! ( ben oui … )

De + tu auras à réindenter le code. J’ai testé le script, il fonctionne bien sur mon sys

Fait bien attention a FTP qui peut te donner des problèmes identiques et difficile à cerner !

Bonne année à tous :stuck_out_tongue:

Notes : référence bibliographique: Christophe Blaess
J’espère qu’il ne reste pas de “coquilles”

#18

Bonjour,

À ton service, debynoob. Pour avoir, quelques fois, été exposé à ce problème de fin de ligne, je peux te dire que la leçon est vite apprise !!!
Je comptais bien avoir tapé dans le mille mais à aucun moment je n’espérais avoir deux “félicitations” !

Rantanplan aussi ! ton super script, est, pour moi inutile car il existe le paquet dos2unix qui ajoute deux commandes : dos2unix et unix2dos.
Quand la commande [i]dos2unix[/b] n’est pas disponible, j’utilise un tr comme cela :

cat fichier_dos.txt | tr '\015' ' ' > fichier_unix.txt

cf man de ascii où l'on apprend cela Oct Déc Hex Car. Oct Déc Hex Car. 015 13 0D RC '\r' (retour chariot) 115 77 4D M)

LeDub très man

#19

Bonjour,

Pour cette histoire de conversion, j’utilisais également dos2unix auparavant. Mais comme le dit si justement Ledub, il n’est pas installé par défaut.

C’est pourquoi je procède ainsi :

Au passage, pour savoir facilement si un fichier contient du formalisme dos : cat -e fichier

#20

Hello ! :wink:

Tu mérites des félicitations parce que tu as procédé par ordre et logique, tu as posé les bonnes questions ! :stuck_out_tongue:

Faut pas exagérer ! :005 c’était juste à titre pédagogique, parce que

me faisait mal aux yeux ( n’en prend pas ombrage stp debynoob, il n’y a aucune honte à débuter, accroche toi :smiley: )

D’ailleurs cette construction [size=85][[ "$REPLY" != [yYoO] ]] [/size]ne marche pas (à cause de [oOyY] ?) , mieux vaut écrire qque chose dans ce genre :
[size=85][code]echo "Réponse ? "
read
case “$REPLY” in
O* | o* | y* | Y* ) # évidemment on aurait pu écrire [oOyY]* mais c’est pour voir le |
/chemin/vers/hello.sh ;;

  • ) exit 1 ;;
    esac
    [/code][/size]

Inutile pour moi également ! :033

[quote=“LeDub”][size=85] cat fichier_dos.txt | tr '\015' ' ' > fichier_unix.txt[/size]

[size=85] cf man de ascii où l'on apprend cela Oct Déc Hex Car. Oct Déc Hex Car. 015 13 0D RC '\r' (retour chariot) 115 77 4D M)[/size][/quote]
Intéressant tout ça ! faut que je note ça

Ah le tombeur de ces dames ! c’est cool d’avoir de l’humour

Au plaisir mano :033