Besoin d'aide pour un script Bash

[Soolfly]

Bonjour à tous,

Dans le cadre de mon travail, j'aimerais transformé un script Batch vers un script Bash.

Ce script à pour but de se connecter à des machines distantes sur un réseau local grâce à la commande net use.

Avec un peut de doc (RTFM MAN), j'ai tenté d'obtenir la même chose en Bash avec Samba, plus précisément avec la commande smbclient.

Dans MAN, j'ai tenter plusieurs options propres à smbclient tel que, smbclient -U, mais apparement l'interpréteur de commande n'aime pas ^^

Mais il y a quelques syntaxes dans Bash que je ne maîtrise pas...

Voici le script Batch à transformé :

@echo off
set nomApp=SupprImprDataCard.bat
set chemin=local$\Batch

for /d %%x in (1,2,3,4,5,6,8,9,10,11,12,15,16,17,18,19,20) do (
echo *** Connexion TPV-%%x
net use \\172.16.1.%%x /user:username "password"
copy ".\%nomApp%" "\\172.16.1.%%x\%chemin%"
net use \\172.16.1.%%x /d
echo *** Fin Connexion TPV-%%x 
echo.
pause 
)

Merci d'avance

[Mephisto]

nomApp=SupprImprDataCard.bat
chemin=`pwd` #absolument pas sur...

for x in 1 2 3 4 5 6 8 9 10 11 12 15 16 17 18 19 20
do
   echo "*** Connexion TPV-$x"
   if ! mount.cifs //172.16.1.$x/$chemin /mnt -o "user=username,password=password" >/dev/null 2>&1; then
       echo "failed to connect to 172.16.1.$x" >&2
       echo "    dmesg | tail may help..." >&2
   else
       cp -pf ./$nomApp /mnt
       umount /mnt
   fi
   echo "*** Fin Connexion TPV-$x"
   read a
done

1) desole, je ne vois pas ce que fait local$\Batch

2) j'imagine que tu veux monter des serveurs samba ? auquel cas, le plus simple est de mount, et donc monter un partage en particulier (d'ou le mount [...]/$chemin ; si c'est pas le cas, donne-nous plus de details)

3) le read a attendra la touche entree ; est-ce le cas de pause ? ou fonctionne-t-il avec n'importe quel caractere ?

[Soolfly]

Salut Méphisto

Merci pour ta réponse !

Alors, pour ce qui est de la déclaration de la variable chemin au début du script...

C'est le répertoire de partage par défaut sur les machines auxquelles je veux accéder ( 1 à 20). Le chemin du partage est en réalité :

chemin=erg$\Batch

Pour ce qui est de la commande "Pause" dans Batch, effectivement, en pressant la touche Entrée, l'invite de commande se ferme. Ca doit surement être pareil pour "read a" dans Bash. (pas encore testé)

Par contre je n'ai pas bien saisi exactement le "mount.cifs". CIFS est un systeme de fichier Unix reconnu par les systeme Windows NT ?

[Amour]

CIFS est l'après SMBFS, c'est le système de fichiers réseau utilisé par Windows

[TeKa]

nomApp=SupprImprDataCard.bat
chemin=`pwd` #absolument pas sur...

for x in 1 2 3 4 5 6 8 9 10 11 12 15 16 17 18 19 20
do
   echo "*** Connexion TPV-$x"
   if ! mount.cifs //172.16.1.$x/$chemin /mnt -o "user=username,password=password" >/dev/null 2>&1; then
       echo "failed to connect to 172.16.1.$x" >&2
       echo "    dmesg | tail may help..." >&2
   else
       cp -pf ./$nomApp /mnt
       umount /mnt
   fi
   echo "*** Fin Connexion TPV-$x"
   read a
done

1) desole, je ne vois pas ce que fait local$\Batch

2) j'imagine que tu veux monter des serveurs samba ? auquel cas, le plus simple est de mount, et donc monter un partage en particulier (d'ou le mount [...]/$chemin ; si c'est pas le cas, donne-nous plus de details)

3) le read a attendra la touche entree ; est-ce le cas de pause ? ou fonctionne-t-il avec n'importe quel caractere ?

Etant donné qu'il s'agit d'un script Bash, je me permets quelques retouches.

Parce que c'est plus facile à taper et plus pratique en cas d'inclusions :

chemin=$(pwd)

Parce que c'est bien d'être feignant :

for x in $(seq 1 20)

Ensuite personnellement, j'aime beaucoup les conditions encadrées de [[ ]], ça facilite la lecture et ça offre plus de souplesses (notamment puisqu'on peut remplacer les '-o' et '-a' par || et &&, foutrement plus évidents et lisibles).

:)

[Soolfly]

Parce que c'est bien d'être feignant :

for x in $(seq 1 20)

Merci TeKa pour ces précisions ! C'est vrai que c'est quand même plus pratique

[Mephisto]

C'est le répertoire de partage par défaut sur les machines auxquelles je veux accéder ( 1 à 20). Le chemin du partage est en réalité :

chemin=erg$\Batch

ok, mais comment est évalué erg\$Batch ? c'est une variable déjà setté ?

ça sort d'où ? ça fait quoi ?

mea culpa pour le seq

utiliser $(pwd) au lieu de `pwd` pourrait ne pas fonctionner sur certain shells

tant que tu reste sur du classique avec un bash, tout se passera bien

mais ça donne des habitudes...

et pour ce qui est des crochets au if : oui, si c'est bien test qu'on veut invoquer (rappellons que [ -> test)

si je n'en ai pas mis au mout.cifs, c'est qu'un test n'aurait pas lancé le mount, mais aurait juste testé la chaîne

-a / -o chaîne des tests sur des chaînes (le binaire appelé est implicitement test)

&& / || chaînent des commandes (le binaire appelé est explicitement écrit)

if ls ; then
echo OK
else
echo failed
fi

if [ ls ]; then
echo OK
else
echo failed
fi

le premier if renvoit bien le resultat du ls et on rentre dans OK (ret=0)

le second if ne renvoit que le OK, car il n'a fait que tester l'existance de la chaîne (et, comme elle existe, ret=0)

[theocrite]

Parce que c'est bien d'être feignant :

for x in $(seq 1 20)

Autant être faignant jusqu'au bout et utiliser "seq 20".

[TeKa]

Parce que c'est bien d'être feignant :

for x in $(seq 1 20)

Autant être faignant jusqu'au bout et utiliser "seq 20".

Pas faux... Ça fait (malheureusement trop) longtemps que je n'ai pas pu faire mumuse avec des scritps Bash, je me rouille...

utiliser $(pwd) au lieu de `pwd` pourrait ne pas fonctionner sur certain shells

tant que tu reste sur du classique avec un bash, tout se passera bien

mais ça donne des habitudes...

C'est pourquoi je l'ai précisé : puisqu'on joue avec Bash, on peut le faire. Et on doit le faire !

Mais c'est sur qu'on prend de mauvaisesbonnes () habitudes qui peuvent nous faire perdre du temps face à un nouveau shell qui a ses propres spécificités...

et pour ce qui est des crochets au if : oui, si c'est bien test qu'on veut invoquer (rappellons que [ -> test)

si je n'en ai pas mis au mout.cifs, c'est qu'un test n'aurait pas lancé le mount, mais aurait juste testé la chaîne

-a / -o chaîne des tests sur des chaîne (le binaire appelé est implicitement test)

&& / || chaînent des commandes (le binaire appelé est explicitement écrit)

if ls ; then
echo OK
else
echo failed
fi

if [ ls ]; then
echo OK
else
echo failed
fi

le premier if renvoit bien le resultat du ls et on rentre dans OK (ret=0)

le second if ne renvoit que le OK, car il n'a fait que tester l'existance de la chaîne (et, comme elle existe, ret=0)

'Tain il semblerait que je me rouille vraiment... Toujours est-il que je parlais du builtin [[, pas de la commande [ (test). Donc "non, non" pour && et ||, joue avec ces 3 zouaves et tu verras.

Sans Bash sous la main pour vérifier ce que j'avançais, je dis plus rien...

[Mephisto]

Toujours est-il que je parlais du builtin [[, pas de la commande [ (test).

[ et [[ fonctionnent de la meme facon, pour autant que je sache (du moins, je l'ai toujours vu comme ca, et n'utilise donc que '[', qui n'est pas un builtin et donc, comme pour les $(), pas dependant du shell)

rajouter des &&/|| dans un [[ ]] syntax error ; et de toute facon le binaire n'est pas appele

[[ expression ]]

Return a status of 0 or 1 depending on the evaluation of the

conditional expression expression. Expressions are composed of

the primaries described below under CONDITIONAL EXPRESSIONS.

Word splitting and pathname expansion are not performed on the

words between the [[ and ]]; tilde expansion, parameter and

variable expansion, arithmetic expansion, command substitution,

process substitution, and quote removal are performed. Condi‐

tional operators such as -f must be unquoted to be recognized as

primaries.

l'utilisation de '['/'[[' pour verifier le resultat d'une commande se fera avec des backquotes, ou a coup de $(), pour verifier la valeur de retour (-ne 0 / -eq 0)

[TeKa]

De mémoire (j'oublie vite les trucs que je n'utilise pas), je faisais des trucs comme ça :

if [[ test1 ]] && [[ test2 ]]
then
 echo lol
fi

Ensuite si le test porte sur une commande, sans doute que je faisais

[[ $(commande) ]]

.

[uzak]

utiliser $(pwd) au lieu de `pwd` pourrait ne pas fonctionner sur certain shells

tant que tu reste sur du classique avec un bash, tout se passera bien

mais ça donne des habitudes...

C'est pourquoi je l'ai précisé : puisqu'on joue avec Bash, on peut le faire. Et on doit le faire !

Mais c'est sur qu'on prend de mauvaisesbonnes () habitudes qui peuvent nous faire perdre du temps face à un nouveau shell qui a ses propres spécificités...

Je suis pas trop d'accord avec ça. Tu sais jamais ce que ton scripts va devenir. Dans 5-10 ans, il se peut qu'il soit encore utilisé, et tu ne seras plus là pour en parler.

Là où je bosse, les scripts sont faits pour ksh. Cependant, tous les scripts n'ont pas le #!/bin/ksh au début.

Quand tu arrives sur un env ou le shell par défaut est /bin/sh, ben ton script plante comme un sac (sur le read, pour ceux que ça intéresse).

Autant pour des trucs qui sont particulièrement longs à faire sans les spécificités de tel ou tel shell, je suis pour, autant mettre $(cmd) au lieu de `cmd`, je vois pas ce que ça apporte

[TeKa]

utiliser $(pwd) au lieu de `pwd` pourrait ne pas fonctionner sur certain shells

tant que tu reste sur du classique avec un bash, tout se passera bien

mais ça donne des habitudes...

C'est pourquoi je l'ai précisé : puisqu'on joue avec Bash, on peut le faire. Et on doit le faire !

Mais c'est sur qu'on prend de mauvaisesbonnes () habitudes qui peuvent nous faire perdre du temps face à un nouveau shell qui a ses propres spécificités...

Je suis pas trop d'accord avec ça. Tu sais jamais ce que ton scripts va devenir. Dans 5-10 ans, il se peut qu'il soit encore utilisé, et tu ne seras plus là pour en parler.

Là où je bosse, les scripts sont faits pour ksh. Cependant, tous les scripts n'ont pas le #!/bin/ksh au début.

Quand tu arrives sur un env ou le shell par défaut est /bin/sh, ben ton script plante comme un sac (sur le read, pour ceux que ça intéresse).

Autant pour des trucs qui sont particulièrement longs à faire sans les spécificités de tel ou tel shell, je suis pour, autant mettre $(cmd) au lieu de `cmd`, je vois pas ce que ça apporte

Ouais enfin tu as le droit de documenter tes scripts... J'ai mis en place des normes, documenté mes scripts et fourni des documentations "officielles" pour tous les trucs un peu abscons que j'ai pu utiliser.

Pour ton erreur de première ligne de script, c'est typiquement le genre de truc que nous avions normé. On avait même créé des squelettes de script pour nos traitement pour pas que les développeurs aient trop à se prendre la tête (structure, gestion des paramètres, gestion du code retour), avec un max de fonctions "utiles" centralisées et documentées.

Pour le $() par rapport au `` : c'est plus facile à taper, c'est plus lisible quand tu imbriques avec des guillemets et ça permet d'imbriquer des commandes sans échapper quoi que ce soit dans le style de $(commande1 $(commande2 truc)).

Je devais travailler avec Bash, pas avec sh, ksh ou zsh. J'avais un seul shell à utilisé, je l'ai utilisé aux maximum de ses capacités (ou tout du moins au maximum de mes capacités). Sérieusement, une fois qu'on a assimilé les $(()) pour calculer ou gérer des variables numériques, les ${} pour manipuler des variables textuelles et toutes les autres joyeusetés de Bash, on a du mal à ne pas les utiliser.