Discussion :

[jool]

Bonjour,
J'ai un outil a développer dont la fonction est d'aller vérifier la présence de fichiers et d'aller farfouiller dans des fichiers pour retourner des codes erreurs.
Jusque la tout va bien, puisque je pouvais me faire un script UNIX et ca "suffisait".
Mais le problème c'est que mon chef a besoin d'une interface graphique pour que l'outil soit vraiment interessant à utiliser.

Mon problème, je peux pas développer un tel outil sur l'environement UNIX distant.
Ma question, qu'est ce que je peux utiliser pour developper cet outil qui devra donc accéder à l'environnement UNIX via FTP pour faire les verifications nécéssaires.
De plus l'outil devra peut etre accéder à une base de données.

J'ai conscience de pas etre tres clair puisque le problème ne l'est deja pas vraiment pour moi.
Toute aide est la bienvenue, posez des questions (je pense d'ailleurs que mon problème c'est ca, jem e pose pas les bonnes questions)
merci d'avance

[elitost]

JAVA est peut être ton ami, une application graphique qui piloterais tes scripts existants ?

Sinon, pas d'environnement X sur ton UNIX distant ?

[ggnore]

Tu devrais te renseigner sur dialog. C'est pour faire du pseudo graphique. En fait, c'est du mode texte, mais tu peux avoir des options classiques de menus.

[jool]

alors en fait oui, je vais devoir utiliser des scripts utulitaires existants.
Enfin , disons que me retapper a faire des trucs deja codé, ca me branche moyen

EN effet, un truc (langage? outil de dev?) alternatif serait pas mal.
en gros j'ai pas besoin de 10000 fonctionnalités, il faudrait afficher une liste avec des cases a cocher et un bouton lancer
apres, c'est sur que si y'a moyen d'utiliser des onglets, des boites de parametrage ca serait plus sympa a utiliser mais bon, effectivement je recherche pas des fonctions graphiques tres avancées.

Et non pas d'environnement X sur mon UNIX distant.

[jool]

alors, j'ai un peu plus réflechi au probleme
En gros, je vais ecrire des scripts UNIX qui vont effectuer tout le traitement. ces scripts accederont a une base de données oracle qui servira à stocker tous les paramétrages nécéssaires au traitement.

L'outil graphique servira à piloter ces scripts (merci elitost) via FTP.
Donc quel langage vous semble le plus adapté a ce type d'application. sachant que je connais plutot bien le C, le C++ et JAVA. En ememe temps, c'est un stage, apprendre un nouveau langage n'est pas exclu

merci encore de votre aide

[jool]

Donc au final, le probleme est de savoir, comment je peux acceder l'environnement UNIX distant et comment je peux exeuter des scripts sur cet enviornnement.
Il fut aussi que je puisse récuperer les infos retournées par ces scripts...
Chuis vraiment pas une bête, autrement dit, je pense que je suis dans la m****
est-ce que quelqu'un peut m'aider déjà à trouver une solution adaptée à ces problèmes
merci

[jool]

Et en fait si, il ya un environnement X sur mon UNIX distant mais je connais pas grand chose a tout ca

[jool]

Bon je reformule
EN gros, il me faut depuis un poste acceder à un environnement UNIX distant pour :
- tester la présence de certains fichiers
- lire des logs d'erreurs
- récuperer les lignes contenant des codes d'erreurs

Que puis-je utiliser pour faire ca?

- Appli en C++/Java/VB/Delphi et acces Telnet à la machine UNIX?

- Interface Web et PERL/CGI et Shell UNIX?

AIdez moi si vous avez compris
je suis perdu...
merci d avance

[DaZumba]

C'est bien, tu remplis ton propre post avec tes messages !
Il faut que tu decomposes ton probleme en deux:

1. Recuperer des fichiers sur l'hote distant.

Tu peux rapatrier tes fichiers sur ta machine locale en faisant un rcp ou un ftp (ca s'automatise facilement a l'interieur d'un script) ou tu lances une commande sur l'hote distant avec rsh.
Tout cela se fait simplement avec des scripts shells que tu ecris et lances sur ta machine locale.
Si tu n'es pas sous Linux ou Unix sur ta machine locale, ca complique les choses, et le ftp sera la meilleure solution (pas de rcp, rsh...). Donc ftp des fichiers distants, et tu travailles sur ta machine.

2. Faire une jolie interface graphique autour des scripts shells

Une fois que tes scripts fonctionnent convenablement, tu peux passer au superflu, ajouter une GUI. La, tu as le choix (langage de bas niveau + bibliotheques [e.g. C + GTK], langage de haut niveau [e.g. Java]).
Mais le principal, c'est tout de meme le point 1. Le reste, c'est de la cosmetique.

[jool]

Merci Dazumba

En fait, je remplis mon post tous seul parce que je comprends des trucs au fur et à mesure mais j'ai encore du mal...

la machine locale est sous Win 2000 donc ftp, a priori l'idée c'est ca :

Je lance mon appli
Je lance un traitement, ca envoie un fichier sur la machine distante (FTP).
A la reception de ce fichier, les scripts UNIX de traitement se declenchent et créent un fichier "Rapport"
Le fichier "Rapport" est récupéré (FTP) par l'appli qui tourne sur la machine locale puis affichage du rapport

Vous en pensez quoi de cette solution?

[DaZumba]

Oui, ta solution semble viable, mais la complication est de lancer les scripts UNIX de traitement.

Je lance un traitement, ca envoie un fichier sur la machine distante (FTP).

Ok, ca c'est facile.

A la reception de ce fichier, les scripts UNIX de traitement se declenchent et créent un fichier "Rapport"

Ca, c'est plus dur car il te faut un programme sur la machine Unix qui passe son temps a verifier l'arrivee (ou la modification) de fichiers. C'est faisable. Une solution plus elegante serait d'envoyer une remote command depuis ta machine locale vers la machine distante, mais je ne connais pas l'interfacage Unix/Windows a ce niveau. On pourra peut-etre t'aider dans les forums Windows ou Linux.

Le fichier "Rapport" est récupéré (FTP) par l'appli qui tourne sur la machine locale puis affichage du rapport

Le plus simple est de faire dans l'autre sens, un ftp depuis la machine Unix vers ta machine locale lorsque le traitement est termine.

[jool]

d'accord...
alors en fait, moi, je pensais que c'etait pas possible de faire l'inverse.
A savoir qu'un serveur FTP pouvait déposer un fichier sur un client FTP
je pensais que seul le client FTP pouvait faire les "put" et "get".

Donc effectivement, si c'est possible c'est nettement plus pratique.
En ce qui concerne, le déclenchement des scripts, effectivement, il va falloir un script qui ecoute en permanence. Il y aurait la solution rsh mais ce service ne tourne pas sur l'UNIX distant et le BT UNIX refuse de le faire tourner...

Sinon, quand je me connecte a la machine UNIX j'utilise XClient, est ce que tu penses qu'il pourrait y avoir une solution de ce coté la?

[DaZumba]

je pensais que c'etait pas possible de faire l'inverse.
A savoir qu'un serveur FTP pouvait déposer un fichier sur un client FTP

Oui, je n'avais pas pense a cela. N'utilisant pas Windows, j'ai tendance a considerer qu'il y a un serveur ftp partout... Tu peux faire des tests, sinon tu fais comme tu l'avais prevu, mais il y a un petit probleme de synchronisation (i.e. savoir quand le programme a termine sous UNIX, puis aller chercher les resultats).

Sinon, quand je me connecte a la machine UNIX j'utilise XClient, est ce que tu penses qu'il pourrait y avoir une solution de ce coté la?

Je l'ignore, il faudrait quelqu'un qui connaisse l'interfacage Windows/Unix. Sinon, il te reste la documentation et Google...

Bon courage !

[jool]

vi je vais fouiller de ce coté la
merci encore pour tes reponses
ca me rassure de voir que ce que je raconte n'est pas trop stupide ...
allez hop GOOGLE Style AGAIN!!!!!

[narmataru]

Pourquoi ne pas utiliser une connexion ssh ? comme ça tu as un shell sur la machine distante et tu peux utilise Dialog pour l'interface graphique (ce qui ne demandera que queslques modification sur ton script existant )

doc dialog/xdialog

[jool]

en réalité si je fais du dialog, j'ai plus besoin de me soucier de quoi que ce soit
je fait tout sur la machine UNIX.
Quand le client veut utiliser l'appli, il se connecte a la machine UNIX (com d'hab en fait) et pis il lance mon outil... plus besoin de s'emmerder la vie avec ces problemes de communication etc...
Apres faut voir avec le client si c'est pas trop "rudimentaire" comme interface graphique...