gzip impossible à lancer en perl 10

Version imprimable

16/05/2013, 17h58
loick2000

gzip impossible à lancer en perl 10
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:

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.
19/05/2013, 14h30
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...
19/05/2013, 20h32
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.
20/05/2013, 13h26
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...
21/05/2013, 11h16
loick2000

Citation:

Envoyé par 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...

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.
21/05/2013, 11h54
djibril

Essaye en mettant le chemin complet vers gzip.
21/05/2013, 11h57
loick2000

Citation:

Envoyé par djibril

Essaye en mettant le chemin complet vers gzip.

J'ai déjà essayé, Dos répond exactement pareil.
21/05/2013, 12h02
djibril

Tu peux nous montrer ton programme lorsque tu mets le chemin complet.
21/05/2013, 15h25
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

Citation:

Envoyé par 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

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).

____________________________________________________________________________

Citation:

Envoyé par djibril

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

Le code perl est celui-ci :
Code:

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:

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".

Code:

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: :cfou: !

Essaye mon programme.

22/05/2013, 15h07
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.