OVH Cloud OVH Cloud

Wscript versus Cscript

8 réponses
Avatar
Mousnynao
Bonjour,

Voilà, j'ai un fichier en lot [ Test1.bat ], dont voici le contenu :
REM *****************************
%1 = Script1.vbs "Jeux,Essai"
REM *****************************

Ensuite, j'ai un script [ Script1.vbs ], dont voici le contenu :
'-------------------------------------------------------------------
DIM oArgs
DIM Valeur2, Valeur3
DIM Position

Set oArgs = Wscript.Arguments

If ( oArgs.Count > 0 ) Then
Valeur2 = oArgs(0)
Position = instr(1,Valeur2,",",1)
If (Position > 0) Then
Valeur3 = Mid(Valeur2,1,(Position-1))
End if
End if

Wscript.Quit Valeur3
'-------------------------------------------------------------------

Or même si je passe en mode Cscript par la commande :
Cscript //h:cscript //s
et que je modifie la ligne :
[ Wscript.Quit Valeur3 ]
par la ligne :
[ Cscript.Quit Valeur3 ]

Il bloque toujours avec l'objet WSCRIPT ou CSCRIPT !

Existe-t-il une solution ?

Merci d'avance

mousnynao

8 réponses

Avatar
Jean-Claude BELLAMY
Dans le message :,
Mousnynao a pris la peine d'écrire ce
qui suit :
[...]
Ensuite, j'ai un script [ Script1.vbs ], dont voici le contenu :
[...]
Wscript.Quit Valeur3
'-------------------------------------------------------------------

Or même si je passe en mode Cscript par la commande :
Cscript //h:cscript //s
et que je modifie la ligne :
[ Wscript.Quit Valeur3 ]
par la ligne :
[ Cscript.Quit Valeur3 ]

Il bloque toujours avec l'objet WSCRIPT ou CSCRIPT !
Existe-t-il une solution ?


Tu fais une ÉNORME CONFUSION !!!
Mais je t'accorde des circonsrtances atténuantes, car c'est la faute de
Microsoft qui n'a rien fait pour l'empêcher !

"Wscript" désigne DEUX concepts totalement différents !

1) C'est le nom d'un MOTEUR interpréteur de scripts VBS/WSF/JS
(%systemrooot%system32wscript.exe)
Ce moteur exécute les scripts en mode fenêtré
(par opposition au moteur Cscript qui les exécute dans
une fenêtre de commandes)

2) C'est le nom de la classe principale de l'hôte de script
C'est totalement indépendant du moteur utilisé.

P.ex. les méthodes telles que "wscript.CreateObject",
"wscript.echo" ou "wscript.quit", les propriétés telles que
"WScript.ScriptFullName", sont relatives à cette classe
"wscript", et non pas au moteur "wscript" !

3) Donc même si le moteur utilisé est "Cscript", dans les
scripts on utilisera toujours la classe "wscript"


Et le changement de moteur par les commandes
Cscript //h:cscript //s
ou
Cscript //h:wscript //s

n'induit AUCUNE modification dans les scripts !
Dans ton cas, la ligne "Wscript.Quit Valeur3" doit rester ainsi, sans aucune
modif.
Elle sera également interprétée aussi bien par "wscript.exe" que par
"cscript.exe"

L'erreur de MS est d'avoir choisi le même nom pour un exécutable et pour une
classe !


--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP] -
http://www.bellamyjc.org ou http://jc.bellamy.free.fr

Avatar
Mousnynao
Bonjour,

Tout d'abord, merci pour votre réponse .

Alors, j'en déduit qu'il n'y a pas de solution !

Un fichier en lot ne peut lancer un script et obtenir un retour ?

Merci
@+


Dans le message :,
Mousnynao a pris la peine d'écrire ce
qui suit :
[...]
Ensuite, j'ai un script [ Script1.vbs ], dont voici le contenu :
[...]
Wscript.Quit Valeur3
'-------------------------------------------------------------------

Or même si je passe en mode Cscript par la commande :
Cscript //h:cscript //s
et que je modifie la ligne :
[ Wscript.Quit Valeur3 ]
par la ligne :
[ Cscript.Quit Valeur3 ]

Il bloque toujours avec l'objet WSCRIPT ou CSCRIPT !
Existe-t-il une solution ?


Tu fais une ÉNORME CONFUSION !!!
Mais je t'accorde des circonsrtances atténuantes, car c'est la faute de
Microsoft qui n'a rien fait pour l'empêcher !

"Wscript" désigne DEUX concepts totalement différents !

1) C'est le nom d'un MOTEUR interpréteur de scripts VBS/WSF/JS
(%systemrooot%system32wscript.exe)
Ce moteur exécute les scripts en mode fenêtré
(par opposition au moteur Cscript qui les exécute dans
une fenêtre de commandes)

2) C'est le nom de la classe principale de l'hôte de script
C'est totalement indépendant du moteur utilisé.

P.ex. les méthodes telles que "wscript.CreateObject",
"wscript.echo" ou "wscript.quit", les propriétés telles que
"WScript.ScriptFullName", sont relatives à cette classe
"wscript", et non pas au moteur "wscript" !

3) Donc même si le moteur utilisé est "Cscript", dans les
scripts on utilisera toujours la classe "wscript"


Et le changement de moteur par les commandes
Cscript //h:cscript //s
ou
Cscript //h:wscript //s

n'induit AUCUNE modification dans les scripts !
Dans ton cas, la ligne "Wscript.Quit Valeur3" doit rester ainsi, sans aucune
modif.
Elle sera également interprétée aussi bien par "wscript.exe" que par
"cscript.exe"

L'erreur de MS est d'avoir choisi le même nom pour un exécutable et pour une
classe !


--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP] -
http://www.bellamyjc.org ou http://jc.bellamy.free.fr






Avatar
Do Re Mi chel La Si Do
Bonsoir !

Un fichier en lot ne peut lancer un script et obtenir un retour ?
Pas directement.




Pour récupérer une valeur en retour, deux idées :
- passer par un fichier batch, créé à la volée, contenant qq chose comme
: "SET A1345", et appelé par un CALL :
- passer par un pipe standard, filtrer avec MORE ou FIND.

Mon choix irait à la première solution, plus stable, et plus facile à
contrôler.

@-salutations

Michel Claveau



Avatar
Jacques Barathon [MS]
"Mousnynao" wrote in message
news:
Bonjour,

Tout d'abord, merci pour votre réponse .

Alors, j'en déduit qu'il n'y a pas de solution !

Un fichier en lot ne peut lancer un script et obtenir un retour ?


Bien sûr que si: il suffit d'exécuter le script VBS, la valeur de retour
sera stockée dans la variable d'environnement %errorlevel%. Par contre il ne
peut s'agir que d'une valeur numérique, cette valeur de retour étant
communément utilisée pour indiquer un état, éventuellement un code erreur.

Si tu veux "échanger" des données entre le CMD et le VBS, tu devras plutôt
passer par un fichier texte, ou alors manipuler une variable d'environnement
directement depuis le VBS.

Jacques

Avatar
Jean-Claude BELLAMY
Dans le message :,
Mousnynao a pris la peine d'écrire ce
qui suit :
Bonjour,

Tout d'abord, merci pour votre réponse .

Alors, j'en déduit qu'il n'y a pas de solution !
??????????????????????

Mais comment en es-tu arrivé à une telle conclusion erronée ?


Un fichier en lot ne peut lancer un script et obtenir un retour ?
Bien sur que SI !!!


A l'aide de l'instruction
wscript.quit <code de retour>

<code de retour> est un nombre entier compris entre 0 et 255
(s'il est absent, c'est analogue à lui avoir attribué la valeur 0)
Et cette valeur se retrouve dans :
- la fonction "if ERRORLEVEL"
- la variable d'environnement %ERRORLEVEL%

(parfaitement équivalents, mais la 2ème écriture, avec variable
d'environnement, n'existe que sous NT et au dela, et non pas sous DOS ni
Win9x. Cette 2ème forme est beaucoup moins ambigüe à manipuler que la
première)

Exemples :
(les 2 fichiers sont à placer dans le même dossier)

Fichier essai.vbs
------- couper ici -------
set args=wscript.arguments
if args.count=0 then wscript.quit 1
num=args(0)
if not isnumeric(num) then wscript.quit 2
if (num mod 3) = 0 then wscript.quit 3
------- couper ici -------

Ficher test.cmd
------- couper ici -------
@echo off
cscript essai.vbs %1
REM on teste le code de retour de essai.vbs
REM fonction "errorlevel"
if errorlevel 3 goto result3
REM variable "%errorlevel%" (plus pratique a mon avis)
goto result%errorlevel%
:result0
echo le nombre transmis au script n'est pas un multiple de 3
goto fin
:result1
echo aucun argument transmis au script VBS
goto fin
:result2
echo l'argument transmis au script n'est pas un nombre
goto fin
:result3
echo le nombre transmis au script est un multiple de 3
:fin
------- couper ici -------


Résultats :

I:VBS>test 2
le nombre transmis au script n'est pas un multiple de 3

I:VBS>test 6
le nombre transmis au script est un multiple de 3

I:VBS>test AAAA
l'argument transmis au script n'est pas un nombre

I:VBS>test
aucun argument transmis au script VBS

--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP] -
http://www.bellamyjc.org ou http://jc.bellamy.free.fr

Avatar
Do Re Mi chel La Si Do
Re !

Un exemple.

D'abord, le VBS :

Set fso=CreateObject("Scripting.FileSystemObject")
Set f=fso.OpenTextFile("TEMP.BAT", 2, True)
f.WriteLine "SET A1=AZERTY"
f.WriteLine "SET B2345"
f.Close


Puis, le batch qui l'utilise :

@echo off
cscript retourbat.vbs
call TEMP.BAT
echo %A1%
echo %B2%


Dans %A1% et %B2% on a récupéré les valeurs retournée par le .VBS


@-salutations

MCI




PS : à noter que l'on peut faire un VBS plus court :
CreateObject("Scripting.FileSystemObject").OpenTextFile("TEMP.BAT",
2, True).Write("SET A1ªAAA")
Avatar
Mousnynao
Bonjour,

Encore une fois, merci à tous pour vos réponse.

De script à script, je réussi malgré tout à récupérer
une chaine de caractères. Mais voilà, il s'agit d'un
vieux système qui appelle un fichier en lot pendant
son exécution, c'est pourquoi je voulais effectuer
un traitement en VBS et retourner le résultat au
fichier en lot lancer par le système.

Mais voilà, pour un octet je n'ai pas de message d'erreur,
mais pour une chaine de caractères, il plante toujours
sur la ligne "Wscript.Quit Valeur2".

Maintenant, grâce à vous tous je comprends mieux la
mécanique. Ainsi je dirais qu'il n'y a pas de solution direct.
Bien entendue les solutions de contournement proposées
devrait fonctionner, mais personnellement je cherche
toujours la "bonne méthode" plutôt que la voie de
contournement.

Je n'ai probablement pas été très clair dans mes écrits.
L'idée de passer ma chaine dans une variable d'environnement
me semble acceptable à ce stade ci du projet.

Donc, merci à tous pour vos éclairssissement

Amicalement
mousnynao


Bonjour,

Tout d'abord, merci pour votre réponse .

Alors, j'en déduit qu'il n'y a pas de solution !

Un fichier en lot ne peut lancer un script et obtenir un retour ?

Merci
@+


Dans le message :,
Mousnynao a pris la peine d'écrire ce
qui suit :
[...]
Ensuite, j'ai un script [ Script1.vbs ], dont voici le contenu :
[...]
Wscript.Quit Valeur3
'-------------------------------------------------------------------

Or même si je passe en mode Cscript par la commande :
Cscript //h:cscript //s
et que je modifie la ligne :
[ Wscript.Quit Valeur3 ]
par la ligne :
[ Cscript.Quit Valeur3 ]

Il bloque toujours avec l'objet WSCRIPT ou CSCRIPT !
Existe-t-il une solution ?


Tu fais une ÉNORME CONFUSION !!!
Mais je t'accorde des circonsrtances atténuantes, car c'est la faute de
Microsoft qui n'a rien fait pour l'empêcher !

"Wscript" désigne DEUX concepts totalement différents !

1) C'est le nom d'un MOTEUR interpréteur de scripts VBS/WSF/JS
(%systemrooot%system32wscript.exe)
Ce moteur exécute les scripts en mode fenêtré
(par opposition au moteur Cscript qui les exécute dans
une fenêtre de commandes)

2) C'est le nom de la classe principale de l'hôte de script
C'est totalement indépendant du moteur utilisé.

P.ex. les méthodes telles que "wscript.CreateObject",
"wscript.echo" ou "wscript.quit", les propriétés telles que
"WScript.ScriptFullName", sont relatives à cette classe
"wscript", et non pas au moteur "wscript" !

3) Donc même si le moteur utilisé est "Cscript", dans les
scripts on utilisera toujours la classe "wscript"


Et le changement de moteur par les commandes
Cscript //h:cscript //s
ou
Cscript //h:wscript //s

n'induit AUCUNE modification dans les scripts !
Dans ton cas, la ligne "Wscript.Quit Valeur3" doit rester ainsi, sans aucune
modif.
Elle sera également interprétée aussi bien par "wscript.exe" que par
"cscript.exe"

L'erreur de MS est d'avoir choisi le même nom pour un exécutable et pour une
classe !


--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP] -
http://www.bellamyjc.org ou http://jc.bellamy.free.fr








Avatar
Mousnynao
Bonjour,

Pour ne pas introduire quelqu'un en erreur, je rajoute ceci :

J'ai écrit une bourde :
"De script à script, je réussi malgré tout à récupérer une chaine de
caractères."

Le script plante aussi, je ne peux passer qu'un octet !

mousnynao


Bonjour,

Encore une fois, merci à tous pour vos réponse.

De script à script, je réussi malgré tout à récupérer
une chaine de caractères. Mais voilà, il s'agit d'un
vieux système qui appelle un fichier en lot pendant
son exécution, c'est pourquoi je voulais effectuer
un traitement en VBS et retourner le résultat au
fichier en lot lancer par le système.

Mais voilà, pour un octet je n'ai pas de message d'erreur,
mais pour une chaine de caractères, il plante toujours
sur la ligne "Wscript.Quit Valeur2".

Maintenant, grâce à vous tous je comprends mieux la
mécanique. Ainsi je dirais qu'il n'y a pas de solution direct.
Bien entendue les solutions de contournement proposées
devrait fonctionner, mais personnellement je cherche
toujours la "bonne méthode" plutôt que la voie de
contournement.

Je n'ai probablement pas été très clair dans mes écrits.
L'idée de passer ma chaine dans une variable d'environnement
me semble acceptable à ce stade ci du projet.

Donc, merci à tous pour vos éclairssissement

Amicalement
mousnynao


Bonjour,

Tout d'abord, merci pour votre réponse .

Alors, j'en déduit qu'il n'y a pas de solution !

Un fichier en lot ne peut lancer un script et obtenir un retour ?

Merci
@+


Dans le message :,
Mousnynao a pris la peine d'écrire ce
qui suit :
[...]
Ensuite, j'ai un script [ Script1.vbs ], dont voici le contenu :
[...]
Wscript.Quit Valeur3
'-------------------------------------------------------------------

Or même si je passe en mode Cscript par la commande :
Cscript //h:cscript //s
et que je modifie la ligne :
[ Wscript.Quit Valeur3 ]
par la ligne :
[ Cscript.Quit Valeur3 ]

Il bloque toujours avec l'objet WSCRIPT ou CSCRIPT !
Existe-t-il une solution ?


Tu fais une ÉNORME CONFUSION !!!
Mais je t'accorde des circonsrtances atténuantes, car c'est la faute de
Microsoft qui n'a rien fait pour l'empêcher !

"Wscript" désigne DEUX concepts totalement différents !

1) C'est le nom d'un MOTEUR interpréteur de scripts VBS/WSF/JS
(%systemrooot%system32wscript.exe)
Ce moteur exécute les scripts en mode fenêtré
(par opposition au moteur Cscript qui les exécute dans
une fenêtre de commandes)

2) C'est le nom de la classe principale de l'hôte de script
C'est totalement indépendant du moteur utilisé.

P.ex. les méthodes telles que "wscript.CreateObject",
"wscript.echo" ou "wscript.quit", les propriétés telles que
"WScript.ScriptFullName", sont relatives à cette classe
"wscript", et non pas au moteur "wscript" !

3) Donc même si le moteur utilisé est "Cscript", dans les
scripts on utilisera toujours la classe "wscript"


Et le changement de moteur par les commandes
Cscript //h:cscript //s
ou
Cscript //h:wscript //s

n'induit AUCUNE modification dans les scripts !
Dans ton cas, la ligne "Wscript.Quit Valeur3" doit rester ainsi, sans aucune
modif.
Elle sera également interprétée aussi bien par "wscript.exe" que par
"cscript.exe"

L'erreur de MS est d'avoir choisi le même nom pour un exécutable et pour une
classe !


--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP] -
http://www.bellamyjc.org ou http://jc.bellamy.free.fr