Discussion :

[loick2000]

Bonjour,

Je programme depuis quelques temps déjà, mais là je suis perdu...

J'ai un perl qui génère un petit compress.cmd en c:\temp.
gzip fonctionne parfaitement en ligne de commande, il est en c:\windows\system32.

le cmd contient :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
J: 
cd DUMP_ORACLE 
gzip fichier_03.dump 
rename fichier_03.dump.gz 20130411_V51.20_fichier_03.dump.gz 
move 20130411_V51.20_fichier_03.dump.gz ..\DUMP_HISTORIQUE

Lorsque je lance le cmd par system ("fichier.cmd") dans mon perl, toutes les commandes s'exécute, sauf la ligne avec gzip, dans ce cas windows me donne l'erreur : "gzip is not recognized as an internal or external command, operable program or batch file."

J'ai essayé avec gzip.exe, et même en méttant le chemin complet. j'ai toujours la même anomalie.

Le plus impressionnant, c'est que si je lance le compress.cmd tout seul, il fonctionne parfaitement.

C'est sur un serveur windows 2003 x64 sp2.

J'ai même mis un "echo %PATH% dans le cmd, et à l'exécution par le perl, j'ai bien le c:\windows\system32 dans le path.

Si quelqu'un a une idée, je suis preneur.

Merci d'avance.

[Mr6]

As-tu essayé de l'appeler en lui mettant le path complet ? Parce que même si ton echo est correct, j'ai un doute sur le contexte d'exécution de ton script...

[loick2000]

Oui, j'ai mis aussi le chemin complet, mais ça ne marche pas...

Et surtout, le cmd généré, si je le lance depuis l'explorateur, il marche et lance le gzip, il doit y avoir un truc dans le contexte "dos" qui fait que seules les commandes windows fonctionnent par "system()", mais je ne trouve pas ce que la configuration de cette machine a de différente par rapport aux autres.

[Mr6]

Qui exécute le cmd ? es-tu sûr de l'identité sous laquelle est exécuté le cmd ? quels sont ses droits ? etc...

[loick2000]

Qui exécute le cmd ? es-tu sûr de l'identité sous laquelle est exécuté le cmd ? quels sont ses droits ? etc...

Logiquement, c'est le system() du perl.exe, process fils de mon propre "user", donc en théorie, il a les mêmes droits que le user lui-même. j'ai même vérifié en mettant dans le cmd un "echo %PATH%", qui me donne bien tous les chemins du path.
Et je lance le cmd généré dans la même session, c'est pour cela que je ne saisi pas pourquoi ms/dos refuse de considérer gzip.exe comme un programme exécutable.

[djibril]

Essaye en mettant le chemin complet vers gzip.

[loick2000]

Essaye en mettant le chemin complet vers gzip.

J'ai déjà essayé, Dos répond exactement pareil.

[djibril]

Tu peux nous montrer ton programme lorsque tu mets le chemin complet.

[6ril23]

Et si tu utilises `gzip....` au lieu de system(gzip...)?
Je demande car sous Unix j'ai rencontré des cas où ça fonctionne avec les backquote et pas avec system

J'avoue que ma connaissance est trop limitée pour te dire pourquoi
mais si quelqu'un a la réponse je serait ravi de me perfectionner

[loick2000]

Et si tu utilises `gzip....` au lieu de system(gzip...)?
Je demande car sous Unix j'ai rencontré des cas où ça fonctionne avec les backquote et pas avec system

J'avoue que ma connaissance est trop limitée pour te dire pourquoi
mais si quelqu'un a la réponse je serait ravi de me perfectionner

J'ai essayé, ça ne fonctionne pas, et même en cas de fonctionnement, le résultat ne serait pas celui qui est attendu, car les noms des chemins serait stockés dans le zip, ce que je ne dois pas avoir (parce que le zip est repris ensuite par d'autres prog (pas forcément en shell, et déjà existants).

____________________________________________________________________________

Tu peux nous montrer ton programme lorsque tu mets le chemin complet.

Le code perl est celui-ci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
foreach $fichier (@liste_dump)
{
	open(Hand,">c:\\temp\\compresseur.cmd");
	print Hand "J: \n";
	print Hand "cd DUMP_ORACLE \n";
	print Hand "c:\\windows\\system32\\gzip.exe $fichier \n";
	print Hand "rename $fichier\.gz ${DATE}_V${Version}_$fichier.gz \n";
	print Hand "move ${DATE}_V${Version}_$fichier.gz ..\\DUMP_HISTORIQUE \n";
	close Hand;
	system("c:\\temp\\compresseur.cmd");
}

Ce qui donne comme fichier compresseur.cmd généré :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
J: 
cd DUMP_ORACLE 
c:\windows\system32\gzip.exe fichier_03.dump 
rename fichier_03.dump.gz 20130411_V51.20_fichier_03.dump.gz 
move 20130411_V51.20_fichier_03.dump.gz ..\DUMP_HISTORIQUE

Les commande rename et move sont acceptées, mais ne fonctionnent pas puisque le .gz n'est pas généré, mais le message d'ano est normal.

Et surtout, compresseur.cmd lancé depuis l'explorateur fonctionne parfaitement, c'est bien là mon soucis, Seul le lancement par system() "déconne".

[djibril]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
foreach $fichier (@liste_dump) {
	open( my $fh, '>', "C:/temp/compresseur.cmd");
	print {$fh} "J: \n";
	print {$fh} "cd DUMP_ORACLE \n";
	print {$fh} "C: \n";
	print {$fh} "c:\\windows\\system32\\gzip.exe $fichier \n";
	print {$fh} "rename $fichier\.gz ${DATE}_V${Version}_$fichier.gz \n";
	print {$fh} "move ${DATE}_V${Version}_$fichier.gz ..\\DUMP_HISTORIQUE \n";
	close $fh;
	system("c:\\temp\\compresseur.cmd");
}

Mais un truc qui me dérange sur ton prog. Tu est sur le disque J: et après demande à lancer un prog qui est sur le C: !

Essaye mon programme.

[loick2000]

Non, je ne suis pas sur le disque C mais dans une fenêtre ms/dos virtuelle, puisque le cmd, lorsqu'il fonctionne est en mémoire machine, par contre, on positionne le prompt sur j:\DUMP_ORACLE, et on lance une commande se trouvant dans le path sur un fichier du prompt...

C'est exactement comme si tu lance un COPY, la commande copy est dans une dll qui se trouve en c:\windows\system. C'est le fonctionnement du %PATH%, qui fait que l'on peut utiliser un programme n'importe où sur la machine, du moment que le répertoire est dans le path. C'est le même fonctionnement que sous linux ou Unix

D'ailleurs, il ne dit pas qu'il ne trouve pas gzip, mais il refuse de le prendre pour un exécutable. C'est ça que je ne comprends pas.

Si tu fais C:, le chemin par défaut ne sera plus celui où est stocké le fichier, donc le gzip ne pourra pas compresser le bon fichier.