Ca je ne sais pas trop. Ca depend de comment readline fonctionne.
S'il n'a besoin pour fonctionner que de stdin, a priori il n'y a pas de raisons pour que ca ne fonctionne pas. Apres tout, une touche tapee au clavier envoie un code ASCII.
Maintenant, si readline utilise stdin + autre chose (genre ttyS*) pour gerer plus de choses, comme la detection d'appuis sur des touches multiples, le relachement de touches, etc alors tu risques de ne pas avoir le comportement attendu.
Ceci dit, il me semble que readline doit etre utilise du cote utilisateur (gestion d'un historique ...)
Dans tous les cas, il ne me semble pas opportun d'utiliser readline du cote serveur, alors que tu ne veux recevoir que les commandes tapees par l'utilisateur (quel est l'interet de conserver et de manipuler un historique cote serveur ?)
Donc ce que tu veux certainement faire c'est un read (bloquant ou non bloquant) qui lit une string et la met dans un buffer.
A chaque fois qu'un '\n' est trouve, tu sais que la ligne a ete validee du cote utilisateur et donc tu n'as plus qu'a executer l'action correspondante suivant ton protocole.
Ceci dit, comme l'on dit de nombreux posts avant moi, si tu nous expliquais un peu plus ce que tu voulais faire on pourrait certainement etre un peu plus precis.
Pas du tout efface.
Syslog n'est la que pour logguer les logs d'une application grace a l'appel syslog (voir la manpage).
La definition d'un demon, c'est un programme qui tourne en standalone et qui est decorrele d'une session utilisateur.
Pour faire ca, ca implique quelques fork et quelques changement avec seteuid je crois.
Ensuite, la notion de stdin/stdout est tres subjective. stdin c'est juste le canal 0, stdout c'est juste le canal 1.
Souvent d'ailleurs, un demon comme inetd/xinetd s'amuse avec les descripteurs de la socket et les dup() pour que le serveur auquel il passe la main puisse directement utiliser stdin/stdout comme entree/sortie vers la socket.
C'est un moyen de "passer" la socket d'un processus pere vers un processus fils.
Si tu as envie que ton programme puisse repondre a des requetes utilisateurs, ce n'est pas tres complique :
1- tu lance ton demon (donc fork() et refork() et seteuid())
2- tu ouvres une socket en ecoute
3- lors d'une connection entrante, tu cree la socket cliente
4- ensuite, suivant si tu veux traiter les connections 1 par 1 ou simultanement, tu vas lancer une thread par socket cliente ou non
5- pour repondre a la requete du client, il faut que tu definisse un protocole, c'est a dire le langage compris a la fois par l'application cliente et ton serveur
6- tu lis la requete, tu fais le traitement, tu repond.
En ce qui concerne le protocole, il peut etre binaire ou texte.
S'il est texte, tu pourras alors utiliser telnet pour te connecter a ton serveur.
Un protocole texte peut etre du style :
requete client : HELO
reponse serveur : HELO!
requete client : LIST
reponse serveur : la liste des fichiers d'un repertoire particulier separe par des espaces par exemple.
Il faut evidemment prendre en compte les cas ou le client s'interrompt en plein milieu d'une requete ou de la session. Mais apres c'est de la gestion reseau.
Si ta question c'est comment faire pour rediriger stdin et stdout de mon serveur vers un client, la reponse est "tu peux le faire", mais comme stdin et stdout vont passer par la socket tu devras quand meme prendre en compte les problemes reseaux pour blinder ton serveur, donc autant utiliser directement la socket.
Sinon, fclose(), dup(), sont tes amis.
Tout a fait. Et c'est la ou on voit quelle mentalite a le developpeur : ou il travaille pour les autres (GPL), ou bien il travaille pour lui...
Bon, j'avoue volontiers que c'est assez reducteur ce que j'ecris (allez-y, moinssez moi ! :-), mais lire la license d'un projet indique pas mal la mentalite de l'equipe de dev.
Il n'y a qu'a voir la p'tite derniere de XFree : on sent le gars frustre qui a choppe le gros melon.
Bref, la license est "un poil" modifie par l'ajout d'un header autorisant les programmes faisant des appels systemes a etre non GPL.
Le post de Linus dont je parle plus haut englobait *il me semble* aussi les modules non free.
Voir pour cela un post de Linus qui clarifie tout ca.
Il y explique nottamment ce qu'il considere comme un link.
Un link pour lui etant une dependance forte vers un sous systeme qui fait que le systeme complet ne peut fonctionner sans ce sous systeme.
Dans le cas des modules non free, le systeme peut fonctionner sans. C'est pour ca qu'il estime qu'il n'y a pas a proprement parler de link et donc que le module n'a pas a etre en GPL.
La solution a ce genre de probleme ?
Utiliser une librairie d'abstraction type ACE qui rend tout ca transparent pour l'utilisateur et multi plateforme...
Oui, l'option ide-scsi=hdc indique d'activer l'emulation scsi uniquement pour hdc.
Je ne veux pas dire de betise, mais il me semble que cdrecord, cdrdao ... si tu n'as pas la toute derniere version (qui n'a justement plus besoin de l'emulation scsi) necessitent que tes deux peripheriques (graveur + lecteur) soient en scsi.
En tout cas, je te rassure, ca ne change rien pour tes disque dur.
Chez moi, mon graveur est en scsi et j'ai ete oblige de mettre mon lecteur cd en emulation scsi pour que ca marche.
En resume, tous les fichiers cites par SCO ont ete cree par IBM.
SCO dit qu'IBM n'a pas le droit de le faire car ca constitue un travail derive, et que dans le contrat original UNIX d'ATT, tout travail derive appartient au proprietaire d'UNIX. (donc SCO)
Sauf que Novell a trouve dans une vieille revue d'ATT appelee $echo une clarification de ce que ATT appelle travail derive pour UNIX.
Et a priori ce qui est cree par les clients n'entre pas dans le cadre du travail derive.
Donc tous les fichiers cites par SCO appartiennent bel et bien a IBM qui en fait ce qu'il veut.
C'est aussi valable pour SGI d'ailleurs.
Ben fais plutot une update.
Tu peux meme le faire directement a partir de ton linux ...
1- tu monte ton cdrom de ta Mdk10-rc1
2- tu vires toutes les anciennes sources urpmi que tu avais avant (urpmi.removemedia)
3- tu ajoute la source urpmi de ton cdrom soit en utilisant le hdlist.cz fournit dessus, soit en demandant a urpmi de l'indexer (urpmi.addmedia)
4- tu update urpmi lui meme : $>urpmi urpmi
5- tu update le reste : $> urpmi --auto-select
et vala : apres t'as plus qu'a rebooter;
Resultat : tu gardes toute ta conf, toutes tes preferences, toutes tes donnees et t'es passe a une Mdk10...
Pour le coup, la liste des fichiers et les affirmations sont cette fois tres precises et assez etendu avec des noms, des dates, les features "copiées" etc ...
Si cette "copie" est justifiée, et est jugé en faveur de SCO, alors AMHA Linux risque d'avoir des problemes aux states.
Je ne connais pas assez Linux (ni Sequant d'ailleurs) mais il me tarde de savoir qui va repondre et comment il va repondre ...
Bref, est ce que pour une fois les plaintes de SCO sont fondees ou pas ?
Ils citent quand meme directement Linus Torvald et l'OSDL dans le document...
Pour linker tes applis clientes (comme ton navigateur) avec une couche graphique qui utilise le serveur x, il faut que tu linkes avec xlib. La librairie X cliente. C'est cette librairie qui communique avec le serveur X si je ne m'abuse.
Or la xlib fait aussi partie du projet XFree86 ...
kde n'a jamais packagé quoi que ce soit.
Les packages dispos sont le fait des distribs elles meme.
S'il n'y a pas de packages dispo pour la mandrake c'est uniquement parce que mandrake ne se bouge pas ...
Pendant un temps, Texstar faisait des packages pour la mandrake, mais il me semble avoir lu quelque part qu'ils arretaient ...
Je l'ai teste il y a quelques mois.
Ca marchait plutot pas mal. Saisie des attributs facile, sur une ou plusieurs photos.
Par contre, plantage redibitoire a la creation d'un album html ...
Faudra que je reessaye pour voir si le bug a ete corrige.
Oui, bugzilla. Sinon, tu peux aussi essayer sourceforge, c'est a la fois plus complet : ca ne fait pas que de la gestion de bogues mais a mon avis c'est moins efficace que bugzilla ...
Il y a aussi "Thinking in c++" de Bruce Eckel qui est vraiment pas mal et qui a en plus l'avantage d'etre dispo en ligne et a la commande.
Du meme auteur : "Thinking in Java".
k3b a une option pour ca (options dans une tab de la boite de dialogue au moment du burn) : tu peux choisir le caractere que tu veux pour le remplacement ...
Pour la copie, il suffit d'appeler l'operateur de recopie : '~' (qu'on devra peut etre renommer en := un de ces quatre pour plus de lisibilite).
Bien sur, cette recopie n'est possible que si cet operateur est definit. Si cet operateur n'est pas redefini, la recopie est interdite, tout essai se soldera par une erreur de compilation
[^] # Re: dialogué avec un deamon
Posté par Epsos . En réponse au journal dialogué avec un deamon. Évalué à 1.
S'il n'a besoin pour fonctionner que de stdin, a priori il n'y a pas de raisons pour que ca ne fonctionne pas. Apres tout, une touche tapee au clavier envoie un code ASCII.
Maintenant, si readline utilise stdin + autre chose (genre ttyS*) pour gerer plus de choses, comme la detection d'appuis sur des touches multiples, le relachement de touches, etc alors tu risques de ne pas avoir le comportement attendu.
Ceci dit, il me semble que readline doit etre utilise du cote utilisateur (gestion d'un historique ...)
De plus, d'apres la manpage http://www.rtr.com/winpak/Documentation/readline.htm(...) readline a besoin d'un terminal pour fonctionner (ttyS* il me semble) donc stdin ne lui suffit pas.
Dans tous les cas, il ne me semble pas opportun d'utiliser readline du cote serveur, alors que tu ne veux recevoir que les commandes tapees par l'utilisateur (quel est l'interet de conserver et de manipuler un historique cote serveur ?)
Donc ce que tu veux certainement faire c'est un read (bloquant ou non bloquant) qui lit une string et la met dans un buffer.
A chaque fois qu'un '\n' est trouve, tu sais que la ligne a ete validee du cote utilisateur et donc tu n'as plus qu'a executer l'action correspondante suivant ton protocole.
Ceci dit, comme l'on dit de nombreux posts avant moi, si tu nous expliquais un peu plus ce que tu voulais faire on pourrait certainement etre un peu plus precis.
[^] # Re: dialogué avec un deamon
Posté par Epsos . En réponse au journal dialogué avec un deamon. Évalué à 1.
[^] # Re: dialogué avec un deamon
Posté par Epsos . En réponse au journal dialogué avec un deamon. Évalué à 2.
Syslog n'est la que pour logguer les logs d'une application grace a l'appel syslog (voir la manpage).
La definition d'un demon, c'est un programme qui tourne en standalone et qui est decorrele d'une session utilisateur.
Pour faire ca, ca implique quelques fork et quelques changement avec seteuid je crois.
Ensuite, la notion de stdin/stdout est tres subjective. stdin c'est juste le canal 0, stdout c'est juste le canal 1.
Souvent d'ailleurs, un demon comme inetd/xinetd s'amuse avec les descripteurs de la socket et les dup() pour que le serveur auquel il passe la main puisse directement utiliser stdin/stdout comme entree/sortie vers la socket.
C'est un moyen de "passer" la socket d'un processus pere vers un processus fils.
Si tu as envie que ton programme puisse repondre a des requetes utilisateurs, ce n'est pas tres complique :
1- tu lance ton demon (donc fork() et refork() et seteuid())
2- tu ouvres une socket en ecoute
3- lors d'une connection entrante, tu cree la socket cliente
4- ensuite, suivant si tu veux traiter les connections 1 par 1 ou simultanement, tu vas lancer une thread par socket cliente ou non
5- pour repondre a la requete du client, il faut que tu definisse un protocole, c'est a dire le langage compris a la fois par l'application cliente et ton serveur
6- tu lis la requete, tu fais le traitement, tu repond.
En ce qui concerne le protocole, il peut etre binaire ou texte.
S'il est texte, tu pourras alors utiliser telnet pour te connecter a ton serveur.
Un protocole texte peut etre du style :
requete client : HELO
reponse serveur : HELO!
requete client : LIST
reponse serveur : la liste des fichiers d'un repertoire particulier separe par des espaces par exemple.
Il faut evidemment prendre en compte les cas ou le client s'interrompt en plein milieu d'une requete ou de la session. Mais apres c'est de la gestion reseau.
Si ta question c'est comment faire pour rediriger stdin et stdout de mon serveur vers un client, la reponse est "tu peux le faire", mais comme stdin et stdout vont passer par la socket tu devras quand meme prendre en compte les problemes reseaux pour blinder ton serveur, donc autant utiliser directement la socket.
Sinon, fclose(), dup(), sont tes amis.
[^] # Re: Theo de Raadt décide le fork de Apache
Posté par Epsos . En réponse à la dépêche Theo de Raadt décide le fork de Apache. Évalué à 2.
[^] # Re: Theo de Raadt décide le fork de Apache
Posté par Epsos . En réponse à la dépêche Theo de Raadt décide le fork de Apache. Évalué à 1.
Bon, j'avoue volontiers que c'est assez reducteur ce que j'ecris (allez-y, moinssez moi ! :-), mais lire la license d'un projet indique pas mal la mentalite de l'equipe de dev.
Il n'y a qu'a voir la p'tite derniere de XFree : on sent le gars frustre qui a choppe le gros melon.
[^] # Re: Theo de Raadt décide le fork de Apache
Posté par Epsos . En réponse à la dépêche Theo de Raadt décide le fork de Apache. Évalué à 2.
Bref, la license est "un poil" modifie par l'ajout d'un header autorisant les programmes faisant des appels systemes a etre non GPL.
Le post de Linus dont je parle plus haut englobait *il me semble* aussi les modules non free.
# Re: article Libé autour du Libre et du projet Gnu (i.e. circa RMS)
Posté par Epsos . En réponse au journal article Libé autour du Libre et du projet Gnu (i.e. circa RMS). Évalué à 1.
[^] # Re: Theo de Raadt décide le fork de Apache
Posté par Epsos . En réponse à la dépêche Theo de Raadt décide le fork de Apache. Évalué à 1.
Grosse nuance !
[^] # Re: Theo de Raadt décide le fork de Apache
Posté par Epsos . En réponse à la dépêche Theo de Raadt décide le fork de Apache. Évalué à 1.
[^] # Re: Theo de Raadt décide le fork de Apache
Posté par Epsos . En réponse à la dépêche Theo de Raadt décide le fork de Apache. Évalué à 1.
Il y explique nottamment ce qu'il considere comme un link.
Un link pour lui etant une dependance forte vers un sous systeme qui fait que le systeme complet ne peut fonctionner sans ce sous systeme.
Dans le cas des modules non free, le systeme peut fonctionner sans. C'est pour ca qu'il estime qu'il n'y a pas a proprement parler de link et donc que le module n'a pas a etre en GPL.
S'il y en a qui sont pret a retrouver le post ...
[^] # Re: Theo de Raadt décide le fork de Apache
Posté par Epsos . En réponse à la dépêche Theo de Raadt décide le fork de Apache. Évalué à 4.
# Re: API de programmation système et Linux : et si
Posté par Epsos . En réponse au journal API de programmation système et Linux : et si . Évalué à 3.
Utiliser une librairie d'abstraction type ACE qui rend tout ca transparent pour l'utilisateur et multi plateforme...
[^] # Re: Affaire SCO : des précisions sur le code incriminé
Posté par Epsos . En réponse à la dépêche Affaire SCO : des précisions sur le code incriminé. Évalué à 1.
# Re: Premier journal !
Posté par Epsos . En réponse au journal Premier journal !. Évalué à 2.
Je ne veux pas dire de betise, mais il me semble que cdrecord, cdrdao ... si tu n'as pas la toute derniere version (qui n'a justement plus besoin de l'emulation scsi) necessitent que tes deux peripheriques (graveur + lecteur) soient en scsi.
En tout cas, je te rassure, ca ne change rien pour tes disque dur.
Chez moi, mon graveur est en scsi et j'ai ete oblige de mettre mon lecteur cd en emulation scsi pour que ca marche.
[^] # Re: Affaire SCO : des précisions sur le code incriminé
Posté par Epsos . En réponse à la dépêche Affaire SCO : des précisions sur le code incriminé. Évalué à 3.
J'ai trouve d'autres infos, nottamment ca : http://www.computerworld.com/governmenttopics/government/legalissue(...)
qui etait aussi paru ailleurs mais j'avais pas fait le rapprochement.
En resume, tous les fichiers cites par SCO ont ete cree par IBM.
SCO dit qu'IBM n'a pas le droit de le faire car ca constitue un travail derive, et que dans le contrat original UNIX d'ATT, tout travail derive appartient au proprietaire d'UNIX. (donc SCO)
Sauf que Novell a trouve dans une vieille revue d'ATT appelee $echo une clarification de ce que ATT appelle travail derive pour UNIX.
Et a priori ce qui est cree par les clients n'entre pas dans le cadre du travail derive.
Donc tous les fichiers cites par SCO appartiennent bel et bien a IBM qui en fait ce qu'il veut.
C'est aussi valable pour SGI d'ailleurs.
Ce qui me rassure...
[^] # Re: Migration mdk 9.2 -> mdk 10rc1
Posté par Epsos . En réponse au journal Migration mdk 9.2 -> mdk 10rc1. Évalué à 2.
Tu peux meme le faire directement a partir de ton linux ...
1- tu monte ton cdrom de ta Mdk10-rc1
2- tu vires toutes les anciennes sources urpmi que tu avais avant (urpmi.removemedia)
3- tu ajoute la source urpmi de ton cdrom soit en utilisant le hdlist.cz fournit dessus, soit en demandant a urpmi de l'indexer (urpmi.addmedia)
4- tu update urpmi lui meme : $>urpmi urpmi
5- tu update le reste : $> urpmi --auto-select
et vala : apres t'as plus qu'a rebooter;
Resultat : tu gardes toute ta conf, toutes tes preferences, toutes tes donnees et t'es passe a une Mdk10...
l'est pas belle la vie ?? :-)
# Re: Affaire SCO : des précisions sur le code incriminé
Posté par Epsos . En réponse à la dépêche Affaire SCO : des précisions sur le code incriminé. Évalué à 1.
Si cette "copie" est justifiée, et est jugé en faveur de SCO, alors AMHA Linux risque d'avoir des problemes aux states.
Je ne connais pas assez Linux (ni Sequant d'ailleurs) mais il me tarde de savoir qui va repondre et comment il va repondre ...
Bref, est ce que pour une fois les plaintes de SCO sont fondees ou pas ?
Ils citent quand meme directement Linus Torvald et l'OSDL dans le document...
[^] # Re: Du rififi pour XFree
Posté par Epsos . En réponse à la dépêche Du rififi pour XFree. Évalué à 3.
Or la xlib fait aussi partie du projet XFree86 ...
[^] # Re: Organisez vos photos avec KDE Image Database
Posté par Epsos . En réponse à la dépêche Organisez vos photos avec KDE Image Database. Évalué à 2.
Les packages dispos sont le fait des distribs elles meme.
S'il n'y a pas de packages dispo pour la mandrake c'est uniquement parce que mandrake ne se bouge pas ...
Pendant un temps, Texstar faisait des packages pour la mandrake, mais il me semble avoir lu quelque part qu'ils arretaient ...
# Re: Organisez vos photos ave KDE Image Database
Posté par Epsos . En réponse à la dépêche Organisez vos photos avec KDE Image Database. Évalué à 1.
Ca marchait plutot pas mal. Saisie des attributs facile, sur une ou plusieurs photos.
Par contre, plantage redibitoire a la creation d'un album html ...
Faudra que je reessaye pour voir si le bug a ete corrige.
# Re: gestion de procédure de test
Posté par Epsos . En réponse au journal gestion de procédure de test. Évalué à 1.
# Re: alternative de la fonction fork()
Posté par Epsos . En réponse au journal alternative de la fonction fork(). Évalué à 0.
Sinon, il y a CreateProcess je crois dans l'API win32.
Encore mieux, utilise des threads ...
# Re: bouquin de C++
Posté par Epsos . En réponse au journal bouquin de C++. Évalué à 2.
Du meme auteur : "Thinking in Java".
http://mindview.net/Books(...)
# Re: Vérif' conformité d'une arborescence
Posté par Epsos . En réponse au journal Vérif' conformité d'une arborescence. Évalué à 1.
[^] # Re: Nosicalight: 0.3pre3
Posté par Epsos . En réponse au journal Nosicalight: 0.3pre3. Évalué à 1.
Bien sur, cette recopie n'est possible que si cet operateur est definit. Si cet operateur n'est pas redefini, la recopie est interdite, tout essai se soldera par une erreur de compilation