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.