Programmes Panoramic en ligne de commande

On peut faire en Panoramic des utilitaires en ligne de commande. On peut ainsi appeler un tel programme par:
nom_du_programme nom_du_fichier_à_traiter
ou en faisant glisser un fichier sur son icône, ou en plaçant un raccourci vers ce programme sur le bureau, et en faisant glisser un fichier du bureau sur ce raccourci, ou encore en y collant un fichier par couper/coller.

Voici le code minimal requis pour cela:

Code:

' utilitaire en ligne de commande
'
' Ce programme réalise des traitements en ligne de commande.
' Il peut être appelé dans une fenêtre DOS:
'    cmdutil fichier
'  exemple:  cmdutil "mondossier\monfichier.txt"
' Il peut aussi être exécuté en faisant glisser un fichier
' sur l'icône du programme par l'explorateur.
' On peut aussi placer un raccourci vers cet exécutable
' sur le bureau et y faire glisse des fichiers du bureau,
' même en y collant un fichier par couper/coller.

hide 0

dim file$, i%, s$, rep$

s$ = param_value$(1)
if s$=""
  s$ = "Ce programme doit être appelé en ligne de commande." + chr$(13)+chr$(10)
  s$ = s$ + "Usage:  cmdutil fichier" + chr$(13)+chr$(10)
  s$ = s$ + "    fichier: chemin et nom du fichier à traiter"
  message s$
  terminate
end_if

for i%=len(s$) to 1 step -1
  if mid$(s$,i%,1)="\" then exit_for
next i%
file$ = mid$(s$,i%+1,len(s$))
rep$ = left$(s$,i%)

' --- placer ici le traitement du fichier passé en paramètre
' file$ contient le nom du fichier
' rep$ contient le nom du répertoire
' rep$+file$ représente le chemin complet

message "On traite le fichier "+file$+" dans le répertoire "+rep$

terminate
end

Tiens tiens, voilà une idée intéressante !

PS si je peux me permettre Klaus, tu peux remplacer:

Code:

for i%=len(s$) to 1 step -1
  if mid$(s$,i%,1)="" then exit_for
next i%
file$ = mid$(s$,i%+1,len(s$))
rep$ = left$(s$,i%)

par:

Code:

file$ = file_extract_name$(s$)
rep$ = file_extract_path$(s$)

Si j'ai bien compris, cmdutil.exe c'est l'utilitaire ci-dessus compilé ? mais pour quel usage ? on peut depuis toujours lancer n'importe quel utilitaire écrit en panoramic et compilé en exécutable en ligne de commande avec un paramètre pour n'importe quel traitement (enfin, un traitement particulier au programme)...
J'ai dû rater quelque chose...

L'idéal serait d'avoir des scripts que l'on n'aurait pas besoin de compiler et que l'on pourrait lancer en tapant leur nom sur la ligne de commande, comme avec TCC ou avec les langages de scripts comme Perl, Python etc.

Avec sur la première ligne une instruction style "#!/panoramic " pour identifier l'interpréteur.

Citation :

L'idéal serait d'avoir des scripts que l'on n'aurait pas besoin de compiler et que l'on pourrait lancer en tapant leur nom sur la ligne de commande, comme avec TCC ou avec les langages de scripts comme Perl, Python etc.

ça c'est faisable, il suffit d'avoir les scripts écrits en panoramic et les lancer avec panoramic quand il voit leur demande sur ses paramètres.

@JL35:
Merci pour la réduction de code - j'avais raté cela. Je l'intègre.

Maintenant pour l'utilité d'un tel programme.

Je sais bien qu'un peut lancer un programme Panoramic complié en ligne de commande, avec des paramètres. Sur ce point, j'enfonce des portes ouvertes. Ce qui était une découverte pour moi (et peut-être pas pour les autres), c'est qu'un peut le lancer aussi en faisant glisser un fichier sur son icône, et même sur un raccourci sur le bureau menant à ce programme. C'est d'une grande utilité pour moi: je suis en train de me construire un archiveur personnalisé, et plutôt que de lancer le programme et de choisir un fichier par un dialogue de sélection, je place une icône sur mon bureau et lui colle ou glisse les fichiers que je veux, à partir de l'explorateur de fichiers. Le programme fait alors un archivage avec des options dans une sorte de boite d'entrée. Il suffit ensuite d'affecter des critères (mots-clé, catégories etc) à chaque fichier pour que je puise le retrouver de façon confortable.

Bon, ça, c'est ma cuisine interne. Ce que j'ai découvert, c'est le lancement par un glisser ou copier/coller en récupérant le nom de fichier dans le paramètre.

Et puis, comme tu vois, le programme démarre sans fenêtre visuelle (enfin, c'est tout comme) et fait la différence entre un lancement par ligne de commande ou par double-click. Pour mon application, elle prévoit les deux modes: avec paramètre, elle n'affiche pas la form 0, effectue son travail sur le fichier et termine silencieusement, et sans paramètre, elle affiche une foem 0 normale avec les fonctions permettant de gérer l'archive.

EDIT

@Exdragon: tu m'intéresses. Tu connais un moyen d'exécuter par programme un script Panoramic ? Si oui, je suis preneur !

Bonjour;
Je suis d'un autre monde, car je ne comprends pas ce qui se dit. Dans le monde du DOS, j'étais sur ATARI, et je ne sais pas ce que vous voulez faire. Des explications seraient la bienvenu pour des ignares comme moi.

Citation :

L'idéal serait d'avoir des scripts que l'on n'aurait pas besoin de compiler et que l'on pourrait lancer en tapant leur nom sur la ligne de commande, comme avec TCC ou avec les langages de scripts comme Perl, Python etc.

Si cela concerne les programmes Panoramic qui auraient besoin d'être compilés, je ne travaille plus avec des compilations qui prennent de la place en mémoire. Je procède autrement. Exemple: pour le programme du MemoRich, je pouvant faire de compilation de la partie Auto It, je fais l'inverse. Je lance le programme Panoramic depuis Auto It (il y a 3 lignes en tout sur les 2 programmes à modifier pour changer de sens), et pour autoit j'ai besoin de la compilation de Panoramic., et pour celui-ci je ne le fais pas. Je procède ainsi (j'ai déjà donné la méthode):

Code:

chain "Z:\prg. bas"

C'est ce programme qui est compilé, et sert d'intermédiaire.
En fait le programme est plus compliqué que cela, mais au moment de le lire, il n'est pas adapté pour le forum, et il n'est fait que pour Memo rich. Venant de changer d'ordi, j'ai fait au plus court juste pour ce programme. Mais sur l'autre ordi, je mettais le chemin dans le presse-papier, qui était récupéré par ce programme CHAIN, et exécuté. J'en ai fait aussi un autre, où le nom était dans un fichier à part. Donc avec un seul exécutable, je faisais marché n'importe quel programme.

Je crois qu'Exderagon suggère d'exécuter un source Panoramic à partir d'un autre programme Panoramic. Par exemple:

Code:

dim script$
script$ = "dim i%"+chr$(13)+chr$(10)
script$ = script$ + "i% = val(left$(time$,2))+chr$(13)+chr$(10)

et trouver un moyen d'exécuter ce code créé dynamiquement. Bon, je sais que ce code-là n'a aucun sens, mais tu vois le principe: exécuter un code créé seulement à l'exécution. Ce serait un peu comme si on avait un #INCLUDE dynamique.

La commande CHAIN ne fait pas l'affaire - elle charge bien un nouveau fichier source et l'exécute, mais l'ancien programme est perdu, avec ses variables, ses fichiers ouverts etc. Et pour EXECUTE et EXECUTE_WAIT, il faut être capable de produire la compilation puis la création de l'exe à partir d'un programme, ce que je ne sais pas faire non plus.

Merci klaus, je vois mieux ce que tu voulais dire, et effectivement comme dans le cas que tu cites: exécuter un traitement par glisser déposer un fichier est intéressant, et de manière quasi invisible par surcroit.

@jean-debord il y a aussi les scripts vbs qui sont bien intéressants (nombreux exemples sur le web), qu'on peut exécuter en ligne de commande, ou bien depuis Panoramic, et même fabriquer directement dans le programme panoramic (de même qu'en .bat) avant exécution, j'en ai donné quelques exemples.

Je vais surement passer pour un idiot, mais je ne comprends toujours pas. Et comme je suis certainement le seul à me lancer, je le fais pour tous ceux qui sont comme moi.

Citation :

' --- placer ici le traitement du fichier passé en paramètre
' file$ contient le nom du fichier
' rep$ contient le nom du répertoire
' rep$+file$ représente le chemin complet

Tu y mets quoi la dedans: un programme Panoramic ou quoi? Comment on procède?. Je suppose qu'il faut faire exécuter ou Windows "R".

Vous parlez souvent de ligne de commande. Mois ce que je connaissais avant, c'était de tester une ligne basic, en dehors de l'exécution.

Tu parles aussi de passage de paramètres. Entre programmes Panoramic? Ce n'est pas clair pour moi.

@cosmos70:
On sait que tout programme Panoramic peut être lancé par un autre programme Panoramic, par la commande execute ou execute_wait, en spécifiant le nom du fichier exe (préalablement créé par l'éditeur) et éventuellement un ou plusieurs paramètres. Rien de nouveau à cela.

De la même manière, on peut lancer un tel programme au niveau d'une invite de commandes DOS, et même dans un fichier batch. Là encore, rien de nouveau.

Ce que j'ai découvert, par hasard, c'est qu'on peut aussi lancer un programme Panoramic dans l'explorateir Windows, en faisant glisser un fichier sur l'icône de ce programme. Cela équivaut au lancement au niveau de l'invite DOS avec le nom de ce fichier en paramètres. Et c'est plutôt pratique pour de petits utilitaires. Imagine simplement que tu veux faire ton propre effaceur sécurisé de fichiers. Tu place son icône à un endroit qui te convient, sur le bureau, par exemple. Et tu lui glisses simplement le fichier dessus, comme si tu le glissais dans la corbeille. Et le programme "reçoit" ce nom de fichier et peut effectuer le traitement approprié sur ce fichier.

Maintenant, l'autre idée est différente. Et là, je ne connais pas de solution technique à ce jour. Tu as certainement déjà vu sur ce forum les différentes contributions autour de VBScript. Il s'agit de petits morceaux de code écrit Visual Basic Script qui peuvent s'exécuter directement SANS compilation, car Microsoft met à disposition un interpréteur pour cela, et c'est gratuit. On peut donc, dans un programme Panoramic, construire un morceau de code à la volée et de le faire exécuter, sans pour cela avoir à quitter le programme, sans avoir besoin d'avoir des EXE préparés d'avance. Ces morceaux de code peuvent être créés à la volée, en fonction des besoins dynamiques; on les écrit dans un petit fichier qui sera exécuté alors que le programme application continue. Et c'est là que l'idée est belle mais sans solution pour le moment: au lieu d'utiliser Visual Basic Script et un outil MicroSoft, fût-il gratuit, ce serait bien d'écrire tout cela en Panoramic et d'exécuter le code Panoramic créé dynamiquement ! Un rêve à ce jour.

Il y a cette méthode peut-être

Code:

' voici mon programme appelant, il se nomme calculateur

dim a%
dim b%
dim c%

a%=5
b%=10

#include "calcule.bas"

Code:

' Voici mon programme appelé, il se nomme calcule.bas
c%=a%+b%

print c%

Malheureusement non, Exdragon. #INCLUDE est une directive, pas une commande. Ceci veut dire qu'avant toute exécution, Panoramic construit un source interne en résolvant TOUS les #INCLUDE, même ceux qui se trouvent éventuellement à l'intérieur d'un module inclus par #INCLUDE ! Et la compilation et l'exécutionne commence qu'après ! Tu as beau créer un fichier BAS avec du code Panoramic dedans - ton #INCLUDE sera exécuté AVANT le démarrage du programme, et non au moment où l'exécution passe par l'endroit où ce trouve cette ligne !

Dommage, mais c'était bien tenté !

Je te remercie pour ta réponse. Je commence à comprendre.

Klaus, l'aide dit bien pourtant que le include s'execute à l'endroit de la commande.

Oui toi tu voudrais un programme qui ne charge rien d'autre que lui-même et appelle un script quand il a besoin, mais en basic il n'y a que les solutions que tu connais, merge, execute, include, peut-être qu'il faudrait une invention de Jack

Mis à part les Dll je ne vois rien d'autre moi...(enfin je dis ça mais je ne connais pas bien les DLL

@Exdragon: la doc dit bien:

Citation :

Cette directive #INCLUDE "F" inclut le fichier source F à l'endroit où
la commande est située. Cette ligne est alors remplacée dans le code
par le contenu du fichier F.
La directive #INCLUDE "F" doit être seule sur une ligne du code.
Les 3 lignes suivantes ne sont pas possibles:
instruction:#include "source.bas":instruction
instruction:#include "source.bas"
#include "source.bas":instruction
La directive #INCLUDE "F" est traitée par l'éditeur avant l'exécution
du code. Par conséquent, F doit donc être écrit littéralement car
aucune évaluation sur le nom n'est effectuée.
Par exemple, #include "source"+".bas" n'est pas possible.
Il faut écrire littéralement le nom du fichier: #include "source.bas"

C'est exactement comme si tu faisais un copier/coller dans l'éditeur, AVANT exécution. Par consequent, en aucun cas ceci peut être utilisé pour insérer ou exécuter du code créé à l'exécution, puisque ce code doit déjà exister AVANT l'exécution. Au moment de l'exécution, la ligne #INCLUDE n'existe tout simplement plus - elle est physiquement remplacée par le contenu du fichier auquel elle fait appel.

ET même avec une DLL, je ne peux pas obtenir le résultat recherché, sauf à pouvoir inclure un interpréteur Panoramic dans ma DLL.

Ceci dit, dans l'absolu, et sans évaluer d'éventuelles difficultés, cela devrait être possible pour Jack de donner accès à cette possibilité. Pourquoi ? Parce que le code Panoramic n'est absolument pas compilé avant d'être interprété. Et j'en veux pour preuve ce qui se passe quant un génère un exécutable. Tout le code est placé dans un fichier, avec une copie de l'interpréteur qui contient le point de démarrage, le code Panoramic représentant en fait des "données" pour l'interpréteur. Et on le voit bien quand il y a une erreur: même un label manquant; une variable mal définie, une faute de frappe dans un mot-clé comme dans une commande, passe sans aucun commentaire dans le fichier EXE qui sera construit. Le message d'erreur, identique à celui qu'on aurait eu en exécution directement dans l'éditeur, apparaît alors au moment de l'exécution dans le fichier EXE.

Donc, il y a certainement un moyen technique de pouvoir "étendre" ou "agrandir" la zone de données pour l'éditeur en lui ajoutant une partie de code, étant bien sûr conscient des conséquences s'il y a des erreurs de programmation. Mais seul Jack peut faire cela.

Citation :

Je vais surement passer pour un idiot, mais je ne comprends toujours pas.

@cosmos70:
Ne t'inquiète pas, on est au moins deux à ne pas comprendre. J'ai beau lire et relire ce post, je ne vois pas ce qu'ils veulent faire.

Citation :

Oui toi tu voudrais un programme qui ne charge rien d'autre que lui-même et appelle un script quand il a besoin

Ils (nous^^) veulent faire ça

L'idée, c'est de faire quelque chose analogue à une calculatrice programmable. On pourrait saisir, construire ou autrement créer en cours d'exécution, des formules, expressions ou même des séquences entières de code en Panoramic, et de faire exécuter ceci, comme par exemple avec des fonctions du type;

Code:

resultat_entier% = EXECUTE_CODE(mon_code1$)
resultat_string$ = EXECUTE_CODE$(mon_code2$)

avec la construction ou la saisie du contenu des variables mon_codexx en cours d'exécution, avec un MESSAGE_INPUT$ par exemple. On pourrait ainsi se créer (et s'échanger) toute une petite bibliothèque de fonctions, toutes plus intéressantes les unes que les autres, et les exécuter même dans un programme généré en EXE, sans avoir à reprendre les sources avec l'éditeur pour les intégrer au niveau de la conception.

C'est tout le concept de VBScript, transposé dans une option Panoramic, un PScript quoi.

mon_code1$ pourrait être une routine retournant le nombre de lignes dans un fichier texte, etc.
mon_code2$ pourrait être une routine retournant sous forme d'une chaîne de caractères, le texte d'un document WORD
etc

Citation :

resultat_entier% = EXECUTE_CODE(mon_code1$)

C'était pas "mon_code%" dans celui-ci ?

(Oui je sais on s'en ....c'est juste pour te le faire remarquer^^ )

Ce que je souhaiterais, c'est pouvoir faire avec panoramic ce qui se fait déjà avec Perl, Python, ou même avec le compilateur TCC qui compile des scripts à la volée :

1) On place en première ligne du programme un code indiquant qu'il s'agit d'un programme Panoramic, p . ex.

Code:

#!/panoramic
print "Bonjour !"
end

Ici j'ai utilisé le symbole #! car c'est celui utilisé sous Linux. On peut bien sûr utiliser un autre code.

2) On enregistre le programme sous forme d'un fichier *.bas, p. ex. prog.bas

3) Sur la ligne de commande, on tape :

Code:

prog.bas

Et le programme s'exécute, sans avoir à être compilé !

Cele évite d'avoir à stocker des tas de fichiers *.exe faisant plus de 1 méga chacun. On ne stocke que des petits fichiers *.bas

En fait, il s'agit de faire avec Panoramic ce qui se fait déjà avec Perl ou Python.

Si c'est trop difficile à réaliser, on pourrait se contenter du système suivant :

Code:

panoramic prog.bas

exactement comme on a en VBScript :

Code:

cscript prog.vbs

ou comme on avait avec le QBasic de Microsoft :

Code:

qbasic prog.bas

Cette deuxième solution ne devrait pas être trop difficile à réaliser. Il s'agirait en fait de lancer l'interprétation du programme sans lancer l'éditeur.

C'est une idée géniale et je m'y mets dès ce soir.
Je pense même arriver à ce qu'un double-clic sur prog.bas lance l'exécution de prog.bas sans rien faire d'autre.

Ce sont des idées comme ça qui font avancer PANORAMIC !

@Exdragon:
Non, j'ai mis intentionnellement le $, car ce que je passe à la fonction que j'imagine, c'est bien une chaîne de caractères contenant une ou plusieurs lignes de code Panoramic (potentiellement des centaines). Pour mieux situer le problème, regarde ceci:

Code:

dim mon_code$, mon_resultat%, fichier$, i%
memo 10
...
'  je construis un premier code
fichier$ = "c:\temp\mon_fichier.txt"
mon_code$ = "dim temp_n%, temp_s$ : file_open_read 17,fichier$"+chr$(13)+chr$(10)
while file_eof=0 : file_readln 17,temp_s$ : temp_n% = temp_n% + len(temp_s$)"+chr$(13)+chr$(10)
mon_code$ = ùon_code$ + "end_while"+chr$(13)+chr$(10)
mon_code$ = mon_code$ + "PSCRIPT_RESULT% = temp_n% : exit_pscript"+chr$(13)+chr$(10)
...
' ailleurs, je construis un autre code:
mon_code$ = "PSCRIPT_RESULT% = val(left$(time$,2)) : exit_pscript"+chr$(13)+chr$(10)
..
' ailleurs encode, je prends le code saisi par l'utilisateur dans un memo:
mon_code$ = ""
for i%=1 to count(10)
mon_code$ = mon_code$ + item_read$(10,i%) + chr$(13)+chr$(10)
next i%
...
' et plus loin, j'exécute le code constitué:
mon_resultat% = EXECUTE_CODE(mon_code$)
...

Pour réaliser cela, on aurait:
1. une fonction Panoramic EXECUTE_CODE ou EXECUTE_PSCRIPT qui prend en entrée une chaîne de caractères représentant une suite de commandes Panoramic, et qui se termine soit par la fin de chaîne, soit, si l'on veut sortir au milieu, par la commande EXIT_PSCRIPT
2. une commande EXIT_PSCRIPT active dans du code lancé par EXECUTE_CODE (à l'image de EXIT_FOR)
3. des variables système prédéfinies PSCRIPT_RESULT%, PSCRIPT_RESULT et PSCRIPT_RESULT$ dans lesquelles un Script Panoramic peut déposer des résultats
4. accès à l'ensemble des variables déclarées et visibles dans le programme (comme dans le premier code où je reprends la variable fichier$)
5. de même, accès aux sous-programmes habituelles du programme principal
6. de même, accès aux objets du programme principal

Ces lignes de code s'exécuteraient en fait exactement dans le même contexte que celui du programme normal, sauf que leur code n'est pas figé dans le source du programme, mais peut être constitué à l'exécution. Un vrai script, quoi.

Donc je vois que ça me ramène à ça!
Mais là j'étais tout seul.

OK Klaus, j'ai bien fait de poser la question finalement