Discussion :

[Maniack Crudelis]

Bonjour à tous

Je travaille actuellement sur la portabilité de l'ensemble de mes programmes. A l'origine conçus pour windows, je travaille leur compatibilité linux.
Et là se trouve un problème de taille.
Sur windows, lors du démarrage d'un programme, celui-ci se lance dans une fenêtre dos et elle est utilisée comme sortie standard.
Sur linux, il faut au préalable démarrer un shell, et depuis celui-ci démarrer le programme.

Je souhaite donc trouver une solution pour que, sous linux, le programme se lance dans un terminal et qu'il l'utilise comme sortie standard.
J'ai essayer le démarrage d'un xterm au début du code. Il s'affiche, mais le programme ne l'utilise pas comme sortie standard

J'imagine que les linuxiens codant en C doivent avoir une solution, mais mes recherches n'ont pas abouties

[Jean-Marc.Bourguet]

Non. Le modele de fonctionnement que tu envisages est completement etranger a Unix.

En simplifie tu vas avoir 3 types de programmes:
- ceux qui lisent leur entree standard et ecrivent sur la sortie standard sans se soucier de ce qu'elles designent (fichier, terminal, socket, ...)
- ceux qui ont une interface texte plus evoluee et qui vont exiger que ce soit des terminaux (que ces terminaux soient reels comme un VT100 mis sur la sortie RS-232, un emulateur de terminal, ou un pseudo-terminal communiquant via ssh avec un ordinateur situe a l'autre bout du monde)
- ceux qui utilisent X et donc n'ont pas besoin de lancer un terminal.

(En passant, tu confonds shell -- un interpreteur de commande -- et terminal).

En fait il y a moyen, regarde l'option -S de xterm, mais les cas ou c'est sense de faire ca sont rares -- par exemple une interface graphique sur un debuggeur -- et souvent mieux servie par l'implementation d'un pseudo-terminal dans le programme.

[matafan]

Au lieu de lancer directement ton_appli, lances xterm -e ton_appli. Ca ouvrira un xterm qui va exécuter ton_appli.

[Médinoc]

N'as-tu pas ça directement dans les propriétés du programme, dans l'environnement graphique utilisé?
Il me semble que sous KDE, il y a une case à cocher "run in terminal", pour les programmes (ou peut-être seulement les raccourcis vers eux).

[Maniack Crudelis]

Merci de vos réponses.
Jean-Marc.Bourguet, ta réponse est complète, je t'en remercie, mais aussi complexe .
Et je ne comprend pas l'intérêt de l'option -S.

matafan, l'option -e de xterm semble être idéale. Sur un code de test, le programme utilise xterm comme sortie standard.
C'est parfais pour l'appel de programme par d'autres programmes. Et c'est l'essentiel du fonctionnement de mon programme.
Mais ça oblige à utiliser des raccourcis pour le lancement du programme par l'utilisateur (ou la ligne de commande).

Médinoc, content de te revoir ici. Tu m'as bien aidé lors de ma dernière visite.
Je n'ai pas vu d'option "run in terminal" sur le programme. Par contre j'ai pas essayé avec un raccourci. (Je suis sous KDE 3)
Bien que ça me serais très utile à titre personnel. Le programme est distribué et donc l'intérêt est d'éviter que chaque utilisateur doivent se farcir toutes les cases à cocher.
Mais même avec cette option, le programme se lancerait, dans mon cas, dans la konsole, pas dans un xterm. Je lui préfère xterm qui, il me semble, devrait être un peu près identique dans toutes les distrib.

Je pense que xterm -e devrait me convenir, pour remplacer start sous dos.
Si il existe une solution autre que le raccourci contenant xterm -e ça peut toutefois être intéressant.

Cordialement,
Et encore merci de vos réponse

[matafan]

matafan, l'option -e de xterm semble être idéale. Sur un code de test, le programme utilise xterm comme sortie standard.
C'est parfais pour l'appel de programme par d'autres programmes. Et c'est l'essentiel du fonctionnement de mon programme.
Mais ça oblige à utiliser des raccourcis pour le lancement du programme par l'utilisateur (ou la ligne de commande).

Non, le principe c'est que tu livres un petit script shell qui fait "xterm -e ton_programme", et tu dis aux gens d'utiliser ce script, au lieu de lancer ton_programme.

[matafan]

Sinon peut-être une piste à explorer, si tu ne peux vraiment pas livrer un script en plus de ton programme : dans ton programme (dans le source) tu fais un isatty(1). Si c'est un tty alors tu continue normalement. Sinon, tu fais un execve() de "/usr/bin/xterm -e toi_même".

Un peu crade quand même, parce que ça empèche les utilisateur de rediriger le sortie vers un fichier par exemple, s'il ne veulent pas du xterm.

Ou alors dans ton programme, tu prévoie une option -x qui fait un execve() de "/usr/bin/xterm -e toi_même". Ca laisse le choix aux utilisateurs.

[Maniack Crudelis]

J'avais pas pensé à faire un script
La solution du script conviendra tout à fait pour les programmes principaux. Ces derniers font office de menu principal, et c'est eux qui démarre les autres programmes.

Ta seconde solution, peut être intéressante. Car dans la majorité des cas, il est impossible d'utiliser les programmes en les redirigeant vers un fichier. Car ils attendent des saisies de la part de l'utilisateur.
Et lorsqu'ils sont appelés avec des arguments ils redirigent d'eux même vers un fichier.

Par contre, execve() c'est quoi? Et comment l'utiliser?
J'ajouterais une question, peut-être stupide, l'appel de xterm -e 'prog' au sein du programme lui-même ne risque-t-il pas de provoquer une boucle infinie?

Je viens de tester la solution du script et ça fonctionne parfaitement.

EDIT: Finalement le script ne fonctionne pas si bien que ça.
En effet, il fonctionne correctement lorsque le script est démarré depuis la konsole.
Mais lorsque je fais un double clic sur le script, la fenêtre xterm apparait et disparait aussitôt .
Il est à noté qu'évidemment le code se termine par une pause!

[matafan]

Par contre, execve() c'est quoi? Et comment l'utiliser?

C'est le system call qui permet d'exécuter un programme (exécuter au sens propre : le nouveau programme remplace le programme qui a fait l'appel). Il y a aussi d'autres fonctions de la même famille qui font sensiblement la même chose : execl, execlp, execle, execv, execvp.

J'ajouterais une question, peut-être stupide, l'appel de xterm -e 'prog' au sein du programme lui-même ne risque-t-il pas de provoquer une boucle infinie?

Non, parce que la deuxième fois, le programme s'éxécute dans un tty (puisque tu l'appelles dans un xterm). Donc il ne repart pas sur un exec.

EDIT: Finalement le script ne fonctionne pas si bien que ça.
En effet, il fonctionne correctement lorsque le script est démarré depuis la konsole.
Mais lorsque je fais un double clic sur le script, la fenêtre xterm apparait et disparait aussitôt .
Il est à noté qu'évidemment le code se termine par une pause!

A mon avis le problème c'est juste que quand tu lances le script en cliquant dessus, il ne s'exécute pas dans le répertoire où se trouve le programme à exécuter. Dans ton script, met le chemin absolu de ton exécutable.

[Maniack Crudelis]

Bonjour,

Effectivement mon problème venait du chemin relatif. En mettant le chemin absolu, le script fonctionne parfaitement.
Toutefois, il m'est impossible de toujours connaitre le chemin absolu où se trouvera le programme. Donc j'ai modifié le script pour qu'il prennent en compte son propre chemin. Comme suit:

Code :

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

xterm -e $PWD/test

Sachant que le fichier test se trouve dans ~/Bureau/FTP/
Lorsque j'exécute le script (et en regardant très très vite) j'aperçois que le script obtient le chemin /home/maniack/test

Aurais-je fais une erreur?


J'ai ajouté à mon code de test la fonction execve, mais ça ne fonctionne pas du tout

En exécutant depuis la konsole, je constate que l'affichage se fait sur elle. En exécution directe, aucune fenêtre n'apparait.
Mais je suis pas sûr du tout de mon appel de execve. Que voici:

Code :

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

1
2
3
    char *newargv[] = { NULL };
    char *newenviron[] = { NULL };
    execve("/usr/bin/xterm -e ~/Bureau/FTP/test_execve", newargv, newenviron);

J'ai ajouté newargv et newenviron, pompé sur un site. Car sans eux, j'obtenais une erreur car je n'avais pas assez d'arguments.
Mais le fonctionnement exact de la fonction m'échappe quelque peu.

[ram-0000]

J'essaierai plutôt un truc comme cela

Code :

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

1
2
3
4
5
6
7
8
9
 
char *newenviron[] = { NULL };
char *newargv[10];
   newargv[0] = "/usr/bin/xterm";
   newargv[1] = "-e";
   newargv[2] = "~/Bureau/FTP/test_execve";
   newargv[3] = NULL;
 
    execve(newargv[0], newargv, newenviron);

[Maniack Crudelis]

J'avais déjà essayer cette méthode qui m'envoyait 2 message d'erreur.
J'ai retenté pour être sur avec ton code, et j'obtiens les mêmes erreurs:

"/usr/bin/xterm Xt error: Can't open display:"
"/usr/bin/xterm: DISPLAY is not set"

J'avais supposé que newargv correspond aux arguments envoyés au programme, en l'occurrence xterm.

[matafan]

Ton problème de DISPLAY, c'est parce que tu passes un environnement vide à execve. Par conséquent DISPLAY n'est pas définit après le execve. Utilises plutôt execl ou execv (l'une ou l'autre c'est comme tu veux - elles font la même chose mais ont juste une interface différente). Ces fonctions transmettent au programme exécuté l'environnement courant.

[Maniack Crudelis]

En utilisant execl, ça fonctionne correctement, la fenêtre xterm s'ouvre.
Mais il y a un léger problème...

J'ajouterais une question, peut-être stupide, l'appel de xterm -e 'prog' au sein du programme lui-même ne risque-t-il pas de provoquer une boucle infinie?

Non, parce que la deuxième fois, le programme s'éxécute dans un tty (puisque tu l'appelles dans un xterm). Donc il ne repart pas sur un exec.

Ce n'est pas UNE fenêtre xterm qui s'ouvre, mais une infinité de fenêtre xterm. Heureusement le pc est lent, j'ai le temps de les fermer avant d'être submergé.

[matafan]

Tu as du faire un truc pas comme il faut, ça devrait marcher. Je peux voir ton bout de code ?

[Maniack Crudelis]

Bien sûr, le voila

Code :

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

1
2
3
4
5
6
    char *newargv[10];
    newargv[0] = "/usr/bin/xterm";
    newargv[1] = "-e";
    newargv[2] = "~/Bureau/FTP/test_execve";
    newargv[3] = NULL;
    execl(newargv[0],newargv[0],newargv[1],newargv[2],newargv[3]);

[matafan]

Le tuc qui m'intéresse c'est la partie où tu appelles isatty() pour savoir s'il faut lancer un xterm ou non.

[Maniack Crudelis]

Ne cherche pas plus loin le problème, isatty m'avait quelque peu échappé! Désolé.
Et étrangement en conditionnant execl avec if(!isatty(1)), ça fonctionne beaucoup mieux!

Donc à présent le programme s'exécute dans le xterm, toutefois j'ai un problème de dossier courant. Il se situe dans /home/maniack, alors qu'il devrait être dans ~/Bureau/FTP/.

Hors j'ai besoin du dossier courant, car le programme utilise beaucoup de fichiers se trouvant dans son dossier ou les dossiers parents.
Existe-il un argument pour xterm afin de spécifier le dossier courant?

[matafan]

tu peux toujours faire

Code :

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

1
2
3
4
5
6
char *newargv[] = {
    "/usr/bin/xterm",
    "-e",
    "cd ~/Bureau/FTP; ./test_execve",
    NULL
};

[Maniack Crudelis]

Ok, effectivement, c'est tout bête et je l'utilise régulièrement. Je perd bêtement mes repères sur un environnement linux .

Par contre encore une fois, ça fonctionne ici car je connais le chemin absolu de mon fichier. Mais le programme doit être autonome et connaître de lui-même son emplacement.
Hors, j'avais pour habitude d'utiliser argv[0] pour connaître le chemin absolu du programme. Mais là sur linux j'obtiens un chemin relatif! Es-ce normal?
Et existe il un autre moyen d'obtenir le chemin absolu?

(Je précise que j'ai fais le test de argv[0] avec et sans isatty et execl afin de m'assurer qu'ils n'étaient pas responsable.)

EDIT: Après une vérification sur win, je n'ai le chemin absolu qu'en cas d'exécution en double clic. Si je démarre le programme depuis msdos, j'obtiens là aussi un chemin relatif.