Exécution à distance, problème de répertoire - Shell/Batch - Programmation
Marsh Posté le 29-11-2005 à 18:48:08
Merci
C'est ce que je pourrais me demander, mais alors pourquoi, lorsque je l'exécute depuis l'appli, crée-t-il les fichiers .ps et surtout .pdf au bon endroit ? Et que donc seuls les fichiers _.at et _.at2 ne sont pas où ils devraient être ?
Depuis, j'ai supprimé la recopie des binaires, ça ne changeait en fait rien à l'affaire.
Je mets les scripts d'origine dans le post suivant.
Marsh Posté le 29-11-2005 à 18:52:53
ps2pdf.bat
@echo off |
ps2pdfxx.bat
@echo off |
gssetgs.bat
@echo off |
Marsh Posté le 29-11-2005 à 18:53:28
rajoute des
echo %1 %2 %3 >> chemin accessible en ecriture\debug.txt
dans tes scripts, et execute les va l'appli, pour verifier qu'elle passe bien les parametres attendus
Marsh Posté le 29-11-2005 à 18:54:00
Fred999 a écrit : Merci |
...et dieu sait que je devrais pas hein
Fred999 a écrit : C'est ce que je pourrais me demander, mais alors pourquoi, lorsque je l'exécute depuis l'appli, crée-t-il les fichiers .ps et surtout .pdf au bon endroit ? Et que donc seuls les fichiers _.at et _.at2 ne sont pas où ils devraient être ? |
ah j'avais pas vu que les PS et PDF étaient au bon endroit
je relis les scripts alors
Marsh Posté le 29-11-2005 à 18:54:27
HumanRAGE a écrit : rajoute des |
déjà demandé
Marsh Posté le 29-11-2005 à 18:55:56
doit y avoir un espace en trop quelque part dans les parametres, qui fait que le shift chie dans la colle
Marsh Posté le 29-11-2005 à 18:58:12
:end |
Marsh Posté le 29-11-2005 à 19:11:50
Fred999 a écrit : ps2pdfxx.bat (exécution, voir ligne précédente : ps2pdfxx B:\fichier.ps B:\fichier.pdf B:\)
|
B:\ est il vraiment accessible depuis le repertoire home de l'application (qui est donc le contexte d'execution des scripts ??) ???
utilise
cd /D %3
pour etre sur (le /D permet de changer de drive en cas d'adresse absolue differente du drive courant)
Marsh Posté le 29-11-2005 à 19:34:58
HumanRAGE a écrit : doit y avoir un espace en trop quelque part dans les parametres, qui fait que le shift chie dans la colle |
Merci !
Bon ça a avancé depuis tout à l'heure... J'vous tiens au courant. Mais effectivement on bosse là-d'ssus en ce moment.
Marsh Posté le 29-11-2005 à 19:35:32
B:\ est le répertoire de sauvegarde par défaut des users (récupéré en bdr), ils ont les droits dessus.
Marsh Posté le 29-11-2005 à 19:42:08
Fred999 a écrit : B:\ est le répertoire de sauvegarde par défaut des users (récupéré en bdr), ils ont les droits dessus. |
je ne sais pas quel est le repertoire courant de l'application, mais un "cd" simple, ne peut que se déplacer dans un meme drive
ex:
si l'appli démarre en c:\program files\appli
et que ton script essaye de faire un
cd e:\perso
bah ca foire. seul un
cd /D e:\perso
peut changer de drive en meme temps qu'il change de repertoire.
ca peut expliquer la difference entre quand tu lances a la main en console, et quand c'est l'appli qui le fait. a part la maniere dont sont passé les parametres, seul le repertoire courant change
Marsh Posté le 29-11-2005 à 20:00:28
OK j'vois...
Mais euh bon finalement ça semble être résolu, deux jours de lutte là-dessus (sans compter l'avant, ça a pris plus d'une semaine, l'enfer ces PDF).
Merci en tk, j'posterai la soluce !
Marsh Posté le 29-11-2005 à 18:12:41
Bonjour tlm,
Tout d'abord, désolé pour le titre peu explicite, le problème est amha assez compliqué à résumer en quelques mots.
Conditions de départ
1. Un binaire Windows (PowerBuilder), situé sur le répertoire A, lance un script (ps2pdf.bat), également situé dans le répertoire A, afin de générer un fichier PDF dans le répertoire B.
Le script ps2pdf.bat est récupéré depuis l'appli Ghostscript : il transforme un fichier PostScript (.ps) en fichier PDF.
La commande lancée par l'application est : ps2pdf B:\fichier.ps B:\fichier.pdf B:\
Le script ps2pdf appelle deux autres scripts, ps2pdfxx.bat et gssetgs.bat, situés dans le répertoire A.
2. Lors de l'exécution du script, on doit créer dans le répertoire B:\ quatre fichiers temporaires :
_.at (généré par le script dans B:\)
_.at2 (généré par le script dans B:\)
gswin32.exe (copie de A:\ vers B:\)
gswin32c.exe (copie de A:\ vers B:\)
qui permettent d'obtenir le fichier PDF.
3. Le problème rencontré au départ est que les fichiers temporaires _.at et _.at2 sont créés, avec le script d'origine, dans le répertoire A:\ ; or nos utilisateurs ne disposent pas des droits d'écriture dans ce répertoire (de toute manière, cela poserait des problèmes vu le grand nombre d'utilisateurs).
Problème
J'ai donc modifié le script pour qu'il fonctionne comme expliqué au point 2.
Lorsque j'exécute le script depuis une fenêtre DOS (sous XP), tout fonctionne correctement : les fichiers sont créés au bon endroit et le PDF généré.
Par contre, lorsque je l'exécute à partir de l'application, les fichiers _.at et _.at2 ne sont pas créés dans B:\ mais dans A:\ (ce qui rend l'exécution globale impossible depuis les postes clients) et les fichiers gswin32.exe et gswin32c.exe ne sont pas copiés dans B:\.
Si quelqu'un avait une idée, ça m'aiderait vraiment beaucoup...
Les trois fichiers :
ps2pdf.bat (exécution : ps2pdf B:\fichier.ps B:\fichier.pdf B:\)
@echo off
@rem $Id: ps2pdf.bat,v 1.8 2002/02/21 21:49:28 giles Exp $
echo -dCompatibilityLevel#1.2 >%3_.at
goto bot
:top
echo %1 >>%3_.at
shift
:bot
if not %4/==/ goto top
call ps2pdfxx %1 %2 %3
ps2pdfxx.bat (exécution, voir ligne précédente : ps2pdfxx B:\fichier.ps B:\fichier.pdf B:\)
@echo off
@rem $Id: ps2pdfxx.bat,v 1.13 2002/11/20 03:01:23 alexcher Exp $
rem Internal batch file for calling pdfwrite driver.
rem The files that call this one (ps2pdf*.bat) write the command-line
rem options into _.at, and then pass the last 2 (or fewer) arguments
rem to this file.
call gssetgs.bat %3
echo -q -dSAFER -dNOPAUSE -dBATCH -sDEVICE#pdfwrite >%3_.at2
if "%OS%"=="Windows_NT" goto nt
rem Run ps2pdf on any Microsoft OS.
if %1/==/ goto usage
if %2/==/ goto usage
rem Watcom C deletes = signs, so use # instead.
rem We have to include the options twice because -I only takes effect if it
rem appears before other options.
:run
echo -sOutputFile#%2 >>%3_.at2
cd %3
rem copy /b /y %3_.at2+%3_.at > NUL
echo -c .setpdfwrite -f %1 >>%3_.at2
%3%GSC% @%3_.at @%3_.at2
goto end
:usage
echo Usage: ps2pdf [options...] input.[e]ps output.pdf
goto end
rem Run ps2pdf on Windows NT.
:nt
if not CMDEXTVERSION 1 goto run
if %1/==/ goto ntusage
if %2/==/ goto nooutfile
goto run
:ntusage
echo Usage: ps2pdf input.ps [output.pdf]
echo or: ps2pdf [options...] input.[e]ps output.pdf
goto end
:nooutfile
rem We don't know why the circumlocution with _1 is needed....
set _1=%1
set _outf=%_1:.PS=.pdf%
if %_1%==%_outf% goto addsuff
call ps2pdfxx %1 %_outf%
goto postsuff
:addsuff
qcall ps2pdfxx %1 %1%.pdf
:postsuff
set _1=
set _outf=
:end
rem Clean up.
if exist %3_.at erase %3_.at
if exist %3_.at2 erase %3_.at2
if exist %3gswin32.exe erase %3gswin32.exe
if exist %3gswin32c.exe erase %3gswin32c.exe
gssetgs.bat (exécution : gssetgs B:\)
@echo off
@rem $Id: gssetgs.bat,v 1.5 2002/02/21 21:49:28 giles Exp $
rem Set default values for GS (gs with graphics window) and GSC
rem (console mode gs) if the user hasn't set them.
copy gswin32.exe %1
copy gswin32c.exe %1
if %GS%/==/ set GS=%1gswin32
if %GSC%/==/ set GSC=%1gswin32c
Message édité par Fred999 le 29-11-2005 à 18:13:44