Il faut éditer plusieurs fichiers pour configurer l'ordinateur pour gérer le terminal. Si vous avez de la chance, vous ne devrez éditer que /etc/inittab. On fait ce travail d'édition à partir de la console (ou de n'importe quel terminal qui fonctionne).
Afin de lancer un processus de login sur un port série quand l'ordinateur démarre (ou change de niveau d'exécution) une commande getty doit être placée dans le fichier /etc/inittab. Getty permet de faire fonctionner (GET) un terminal (TTY). Chaque terminal a besoin de sa commande getty. Il y a aussi au moins une commande getty pour la console dans chaque fichier /etc/inittab. Trouvez-la et ajoutez-y les commandes getty pour les vrais terminaux. Ce fichier peut contenir des lignes d'exemples de commandes getty pour les terminaux texte mises en commentaire, et donc tout ce qu'il vous reste à faire est d'enlever les commentaires (enlevez le # au début de la ligne) et de modifier quelques arguments.
Les arguments autorisés dépendent du getty que vous utilisez :
Les deux meilleurs getty pour les terminaux reliés de manière directe sont :
Les deux gettys plus appropriés pour les modems (évitez-les pour les terminaux) sont :
Un getty simple à utiliser uniquement pour les logins sur la console :
Si vous n'avez pas le getty que vous désirez, cherchez-le dans d'autres
distributions et utilisez le programme alien pour le convertir entre
paquets RPM et Debian. Le code source sur
Metalab (logiciels série).
Si vous n'utilisez pas les lignes de contrôle du modem (par exemple si vous n'utilisez que les 3 conducteurs minimums : transmission, réception et masse commune) vous devriez le faire savoir à getty en utilisant un drapeau "local". Le format de celui-ci dépend du getty que vous utilisez.
Un exemple de ligne dans /etc/inittab :
S1:23:respawn:/sbin/getty -L 19200 ttyS1 vt102
S1 vient de ttyS1. 23 veut dire que getty est lancé en entrant dans les niveaux d'exécution 2 ou 3. respawn veut dire que si getty est tué, il se relancera automatiquement. /sbin/getty est la commande getty. Le -L veut dire Local (ignorer les signaux de contrôle du modem). -h (non montré dans l'exemple) permet le contrôle de flux matériel (même chose que stty crtscts). 19200 est la vitesse de transmission. ttyS1 veut dire /dev/ttyS1 (COM2 sous MS-DOS). vt102 est le type de terminal et ce getty donnera cette valeur à la variable d'environnement TERM. Il n'y a pas de fichiers de configuration. Tapez "init q" sur la ligne de commande après avoir édité la ligne de getty et vous devriez apercevoir une invite de login.
Le programme agetty détectera automatiquement la parité configurée dans
le terminal. Excpté si vous utilisez 8bit d'octet de données avec 1-bit de
parité. Si vous utilisez stty pour fixer la parité, agetty la
désactivera automatiquement puisqu'il veut que le bit de parité passe comme
si c'était un bit de donnée. C'est parce qu'il a besoin d'obtenir le dernier
bit (qui peut être un bit de parité) pendant que vous tapez votre nom de
login afin d'auto-détecter la parité. Donc, si vous utilisez la parité, ne
l'activez que du côté du terminal et laissez agetty la détecter
automatiquement et la positionner sur l'ordinateur. Si votre terminal
supporte la parité en réception, l'invite de login sera brouillée jusqu'à ce
que vous tapiez quelque chose et que getty positionne la parité. L'invite
brouillée repoussera les visiteurs etc. qui essaient de se logger. Cela peut
être exactement ce que vous voulez.
Il y a parfois des problèmes avec l'autodetection de parité. Cela arrive
car après la première frappe de votre login, agetty utilise le programme
login pour finir de vous loguer. Si le premier essai de login échoue,
login se relance pour s'occuper des éssais futurs de login (incluant
l'écriture de votre login). Le problème est que seulement agetty peut detecter
la parité tandis que le programme login ne le fait pas. Donc, si vous
remontez dans le programme login pour quelque raison que ce soit et que
la parité n'a pas encore été détectée, vous etes en difficulté tant que le
programme login ne peut pas detecter la parité. Avec une mauvaise parité,
login ne peut pas lire correctement ce que vous écrivez et vous ne pouvez
pas vous loguez. Si votre terminal supporte la réception de parité, vous
continuerez à voir un écran brouillé.
On peut arriver dans cette "boucle de login" de plusieurs façons. Supposez que
vous tapez une ou deux lettres seulement pour votre login et que vous tapez
Entrée. Si ces lettres ne sont pas suffisantes pour la detection de parité,
alors login se lancera avant que la parité soit detectée. Quelque fois ce
problème arrive si vous n'avez pas le terminal allumé et connecté quand
agetty démarre pour la première fois. Si vous restez bloqué dans cette
"boucle de login", une solution est d'attendre à peu près une minute, le temps
qu'agetty se relance dû au "timeout".
Malheureusement, agetty ne peut pas detecter cette parité. Il (fin 1999)
n'y a pas d'options pour desactiver l'auto-detection de parité et cela
detectera les parités incorrects. Le résultat est que le processus de login
sera brouillé et la parité sera mal reglé. Ainsi il ne parait pas faisable
d'essayer d'utiliser des octets de données de 8-bit avec parité.
(Ceci est tiré du vieux Serial-HOWTO de Greg Hankins).
Ajoutez des
entrées pour getty pour utiliser votre terminal dans le fichier de
configuration /etc/gettydefs si elles ne sont pas déjà présentes :
# 38400 bps Dumb Terminal entry DT38400# B38400 CS8 CLOCAL # B38400 SANE -ISTRIP CLOCAL #@S @L login: #DT38400 # 19200 bps Dumb Terminal entry DT19200# B19200 CS8 CLOCAL # B19200 SANE -ISTRIP CLOCAL #@S @L login: #DT19200 # 9600 bps Dumb Terminal entry DT9600# B9600 CS8 CLOCAL # B9600 SANE -ISTRIP CLOCAL #@S @L login: #DT9600
Si vous voulez, vous pouvez faire en sorte que getty affiche des choses
intéressantes dans la bannière de login. Dans mes exemples, je fais afficher
le nom du système et la ligne série. Vous pouvez ajouter d'autres choses :
@B la vitesse courante (évaluée au moment où @B est rencontré).
@D la date courante, au format MM/JJ/AA.
@L la ligne série à laquelle est attaché getty.
@S le nom du système.
@T l'heure courante, au format HH:MM:SS (24 heures).
@U le nombre d'utilisateurs actuellement loggés. C'est le compte
du nombre d'entrées dans le fichier /etc/utmp qui possèdent
un champ ut_name non nul.
@V la valeur de VERSION, donnée dans les fichiers de valeurs par
défaut.
Pour afficher un caractère '@', utilisez soit '\@', soit '@@'.
Quand vous avez fini d'éditer /etc/gettydefs, vous pouvez vérifier
que la syntaxe est correcte en faisant :
linux# getty -c /etc/gettydefs
Assurez-vous qu'il n'y a pas de fichier de configuration getty ou
uugetty pour le port série auquel est attaché votre terminal
(/etc/default/{uu}getty.ttySN ou
/etc/conf.{uu}getty.ttySN), car cela entrera sûrement en
conflit avec le lancement de getty sur un terminal. Enlevez le fichier
s'il existe.
Éditez le fichier /etc/inittab pour lancer getty sur le port
série (en mettant les informations correctes pour votre environnement --
port, vitesse et type de terminal par défaut) :
S1:23:respawn:/sbin/getty ttyS1 DT9600 vt100
Relancez init :
linux# init q
À ce point, vous devriez voir une invite de login sur votre terminal. Vous devrez peut-être appuyer sur Retour pour que le terminal soit attentif.
Le "m" veut dire modem. Ce programme est d'abord destiné aux modems et en mi-1999 ne fonctionnait pas toujours très bien pour les terminaux texte. Il est très mal documenté pour les terminaux et vous devrez parcourir beaucoup de documentation sur les modems pour déterminer comment l'utiliser pour un terminal. Regardez les dernières lignes de /etc/mgetty/mgetty.config pour avoir un exemple de la configuration d'un terminal. [Note du relecteur : je le trouve au contraire bien documenté (janvier 1999) dans man mgetty : un mgetty -r -s 9600 /dev/ttyS0 (par exemple) est suffisant. Le -r indique que la connexion est directe (sans modem).] Ceci sera, espérons-le, réparé dans le futur. Il serait bien d'avoir le même getty à la fois pour les terminaux et les modems mais mgetty nécessite quelques améliorations avant de convenir pour les deux utilisations.
Il y a à la fois une commande "stty" et une commande "setserial" pour
configurer les ports série. Certains (ou tous les) paramètres stty
nécessaires peuvent être positionnés grâce à getty et il peut ne pas être
nécessaire d'utiliser setserial ; l'utilisation de ces deux commandes peut
donc ne pas être nécessaire. Celles-ci (stty et setserial) paramètrent
différents aspects du port série. Stty en fait la plupart tandis que
setserial configure la partie bas niveau comme les interruptions et les
adresses de ports. Pour "sauvegarder" les paramètres, ces commandes doivent
être écrites dans certains fichiers (scripts shell) qui sont lancés à chaque
démarrage de l'ordinateur. Les distributions de Linux fournissent souvent un
script shell qui lance setserial mais en fournissent rarement un qui
lance stty tant qu'on en aura rarement besoin..
N'utilisez jamais setserial avec des portables (PCMCIA). setserial
est un programme vous permettant d'indiquer au logiciel pilote l'adresse
d'entrée/sortie du port série, quelle interruption (IRQ) est positionnée dans
le matériel du port, le type d'UART que vous possédez, etc. Il peut aussi
vous montrer comment le pilote est configuré à ce moment. En plus, il peut
faire des requêtes au matériel (si certaines options sont données).
Si vous avez seulement un ou deux ports séries, ils seront bien configuré
sans utiliser setserial. Autrement (ou si il y'a des problèmes avec ce port série) vous devrez utiliser setserial. En plus du manuel de setserial,
regardez les informations dans /usr/doc/setserial.../ ou autre.
Cela devrait vous indiquer comment setserial se comporte dans votre
distribution de Linux.
Setserial est souvent lancé automatiquement au démarrage par un script
shell. Il ne fonctionnera que si le module série est chargé. Si vous devez
pour une raison ou pour une autre décharger le module série plus tard, les
modifications faites précédemment par setserial seront oubliées.
Setserial doit donc être re-lancé pour les prendre en compte à nouveau.
En plus de le lancer avec un script de démarrage, quelque chose semblable à
setserial se lance quand le module série est chargé. Ainsi quand vous
regardez les messages de démarrage sur l'écran il pourra vous sembler être
lancé deux fois, et en fait c'est ce qui s'est passé.
Setserial peut régler le temps que le port restera actif après qu'il soit fermé (pour sortir les caractères qui sont encore dans leurs buffers dans la RAM principale). C'est necéssaire pour un taux de transferts de 1200 baud ou plus bas. C'est aussi necéssaire pour des vitesses plus rapides si il y'a beaucoup de "contrôle de flux" en attente.
Si votre port série est Plug-and-Play, vous devrez peut-être consulter d'autres HOWTOs, comme Plug-and-Play et Serial.
Avec les bonnes options, setserial peut chercher (à une adresse
d'entrée/sortie donnée) un port série mais vous devez deviner l'adresse
d'entrée/sortie. Si vous lui demandez de chercher /dev/ttyS2 par exemple, il
ne cherchera qu'à l'adresse où il pense trouver ttyS2. Si vous dites à
setserial que ttyS2 est à une adresse différente, alors il cherchera à cette
adresse, etc. Voyez
Recherche.
Setserial ne positionne pas lui-même les IRQ ou les adresses d'entrée/sortie dans le matériel du port série. Ceci est fait soit avec des cavaliers, soit par plug-n-play. Vous devez dire à setserial les valeurs mêmes qui ont été configurées dans le matériel. N'inventez pas simplement des valeurs dont vous pensez qu'elles font joli en les soumettant à setserial. Cependant, si vous connaissez les adresses d'entrée/sortie mais pas l'IRQ, vous pouvez demander à setserial de tenter de déterminer l'IRQ.
Vous pouvez voir une liste des commandes possibles et utilisables (mais pas
les options à une lettre telles que -v pour verbeux -- que vous devriez
normalement utiliser pour déboguer) en tapant simplement setserial sans
argument. Notez que setserial nomme une adresse d'entrée/sortie un "port". Si
vous tapez :
setserial -g /dev/ttyS*
vous verrez quelques informations sur la manière dont ce pilote de périphériques est configuré pour vos ports. Ajoutez un "v" à l'option "-g" pour en voir plus. Mais ceci ne vous dira pas si le matériel dispose vraiment de ces valeurs. En fait, vous pouvez lancer setserial et assigner une adresse d'entrée/sortie purement fictive, n'importe quelle IRQ, et tout type d'UART que vous aimeriez avoir. Alors, la prochaine fois que vous lancerez "setserial ...", il affichera ces valeurs fausses sans se plaindre. Notez que les assignations faites par setserial sont perdues quand le PC est éteint donc il est en général lancé automatiquement quelque part à chaque fois que Linux est démarré.
Afin de tenter de trouver si vous avez un certain type de matériel série,
vous devez d'abord savoir (ou deviner) son adresse d'entrée/sortie (ou le
pilote de périphérique doit en avoir une adresse d'entrée/sortie, sûrement
positionnée précédemment par setserial). Pour tenter de détecter le matériel
physique, utilisez l'option -v (verbeux) et la commande autoconfig de
setserial. Si le message résultant montre un type d'UART tel que 16550A,
alors tout est bon pour vous. Si par contre il affiche un type d'UART
"unknown" (inconnu), alors il n'y a sûrement pas de port série du tout à
cette adresse d'entrée/sortie. Certains ports série bon marché ne
s'identifient pas correctement donc si vous voyez "unknown" vous avez
peut-être quand même un port série à cet endroit.
En plus de faire une auto-détection sur le type d'UART, setserial peut aussi
déterminer automatiquement les IRQs, mais ceci ne fonctionne pas toujours
bien non plus. Dans les versions de setserial>= 2.15, votre dernier test de
recherche peut être sauvé et placé dans le fichier de configuration
/etc/serial.conf qui sera utilisé au prochain démarrage de Linux. Le
script qui lance setserial au démarrage ne fait généralement pas de
recherche, mais vous pouvez le modifier pour qu'il le fasse. Voyez la section
suivante.
Oui, mais... Votre distribution doit deja le faire au démarrage. Mais vous pouvez le customiser. C'est facile à faire avec setserial < 2.15. Ajoutez simplement quelques lignes au fichier qui lance setserial au démarrage. Voyez vieille méthode de configuration : édition d'un script. Par exemple, pour ttyS3 vous ajouteriez :
/sbin/setserial /dev/ttyS3 auto_irq skip_test autoconfig
au fichier qui lance setserial au démarrage. Faites ceci pour chaque port série que vous voulez auto-configurer. Assurez-vous de donner un nom de périphérique qui existe vraiment sur votre machine. Dans certains cas ca ne marchera pas bien à cause du matériel, donc vous pouvez lui assigner un irq et/ou un type d'uart. Par exemple:
/sbin/setserial /dev/ttyS3 irq 5 uart 16550A skip_test
Pour les versions>= 2.15 (à condition que votre distribution ait inclus la modification, Redhat ne l'a pas fait), il est plus difficile de le faire puisque le fichier qui lance setserial au démarrage, /etc/init.d/setserial ou autre n'a pas été prévu pour être édité par l'utilisateur. Il peut ne pas y avoir de commentaires utiles comme il y en avait dans les versions précédentes.
Quand le noyau charge le module série (ou si le "module" est intégré au
noyau) alors seuls ttyS{0-3} sont auto-détectés et le pilote est
configuré avec les IRQs 4 et 3 (peu importe la configuration réelle du
matériel). Vous le voyez sur un message au démarrage comme si setserial
avait été lancé. Si vous utilisez 3 ports ou plus, ceci peut engendrer des
conflits d'IRQ.
Pour régler de tels conflits en donnant à setserial les vraies IRQs (ou pour
d'autres raisons) il peut y avoir un fichier quelque part qui lance
setserial à nouveau. Ceci se passe tôt pendant le démarrage avant que
n'importe quel processus utilise le port série. En fait, votre distribution
peut avoir configuré les choses pour que le programme setserial se lance
automatiquement à partir d'un script au démarrage. On peut trouver plus
d'informations pour gérer cette situation dans /usr/doc/setserial.../ ou
autre.
les versions inferieurs à la 2.15 de setserial, la façon pour
le configurer était d'édité le script shell qui lancait setserial
au démarrage. Avec la version 2.15 (1999) de setserial le
script shell n'est pas édité mais est lancé au démarrage et obtient
ses données à partir d'un fichier de configuration: /etc/serial.conf.
Mais on n'édite normalement jamais /etc/serial.conf. À la place,
utilisez simplement setserial sur la ligne de commande.
Normalement, ce que vous avez modifié avec la commande setserial est sauvé
dans le fichier de configuration (serial.conf) quand vous éteignez
(normalement) ou que vous redémarrez. Ceci ne fonctionne que si
"###AUTOSAVE###" ou similaire se trouve sur la première ligne de serial.conf.
Si vous devez utiliser setserial de manière expérimentale et qu'il ne
fonctionne pas correctement, alors n'oubliez pas de le relancer pour que les
paramètres expérimentaux ne soient pas sauvés par erreur. Le fichier le plus
couramment utilisé pour lancer setserial au démarrage (en restant conforme
avec le fichier de configuration) est maintenant /etc/init.d/setserial
(Debian) ou /etc/init.d/serial (Redhat), ou etc., mais ne devrait normalement
pas être édité non plus.
Pour désactiver un port, utilisez setserial pour le positionner à "uart
none". Le format de /etc/serial.conf apparaît être comme celui des paramètres
placés après "setserial" sur la ligne de commande avec une ligne pour chaque
port. Si vous n'utilisez pas autosave, vous pouvez éditer /etc/serial.conf à
la main. Pour la version 2.15, la distribution Debian installe le système
avec la sauvegarde automatique activée, mais Redhat 6.0 avait simplement un
fichier /usr/doc/setserial-2.15/rc.serial que vous deviez déplacer dans
/etc/init.d/.
BOGUE : en juillet 1999 il un bogue/problème puisqu'avec ###AUTOSAVE### seuls les paramètres de setserial affichés par "setserial -G /dev/ttyS?" (où ? vaut 0, 1, 2, ...) sont sauvés mais pas les autres paramètres. Ceci n'affecte qu'une minorité d'utilisateurs puisque les paramètres non sauvés sont de toute façon rarement utilisés. Cela a été rapporté comme un bogue et peut être réparé maintenant.
Afin de forcer les paramètres courants positionnés par setserial à être
sauvés dans le fichier de configuration (serial.conf) sans éteindre la
machine, faites ce qui se passe normalement quand vous éteignez : lancez le
script shell /etc/init.d/{set}serial stop. La commande "stop"
sauvera la configuration courante mais les ports série continueront de
fonctionner correctement.
Dans certains cas vous pouvez avoir l'ancienne et nouvelle méthode d'installé mais heureusement juste une d'elles se lance au démarrage. Debian étiquette les fichiers obsolètes avec "...pre-2.15".
Avant la version 2.15 (1999) il n'y avait pas /etc/setserial.conf pour configurer setserial. Ainsi vous devez chercher un fichier qui lance setserial au démarrage et l'édité. S'il n'existe pas, vous devez en créer un (ou placer les commandes dans un fichier qui se lance tôt au démarrage). Si un tel fichier est utilisé en ce moment, il se trouve sûrement dans l'arborescence /etc. Mais Redhat <6.0 l'a mis dans /usr/doc/setserial/ bien que vous deviez le déplacer dans l'arborescence /etc avant de l'utiliser. Vous pouvez utiliser "locate" pour essayer de trouver un tel fichier. Par exemple, vous pouvez taper : locate "*serial*".
Ce que pouvez chercher peut s'appeler rc.serial ou 0setserial (Debian). Si un
tel fichier est fourni, il devrait contenir un certain nombre d'exemples
commentés. En décommentant certains d'entre eux et/ou en les modifiant, vous
devriez pouvoir configurer les choses correctement. Assurez-vous que vous
utilisez un chemin valide pour setserial, et un nom de périphérique
valide. Vous pouvez faire un test en exécutant ce fichier à la main (tapez
simplement son nom en tant que super-utilisateur) pour voir si ça fonctionne
bien. Un test comme celui-ci est bien plus rapide que de faire des
redémarrages à répétition pour avoir le bon résultat. Bien sûr, vous pouvez
aussi tester une commande setserial unique en la tapant simplement sur
la ligne de commande.
Le script /etc/rc.d/rc.serial était couramment utilisé dans le passé.
La distribution Debian a utilisé /etc/rc.boot/0setserial. Un autre
fichier qui a été utilisé est /etc/rc.d/rc.local mais ce n'est pas
une bonne idée car il peut ne pas être lancé assez tôt. On a indiqué que
d'autres processus peuvent essayer d'ouvrir le port série avant l'exécution
de rc.local, ce qui entraîne des échecs de communication série.
Par défaut, ttyS0 et ttyS2 partagent l'IRQ 4, tandis que ttyS1 et ttyS3 partagent l'IRQ 3. Le partage des interruptions série n'est permis que si : 1. vous avez un noyau 2.2 ou supérieur, 2. vous avez compilé le support pour le faire et 3. votre matériel série le supporte. Voyez le HOWTO Série, sur le partage des interruptions et les noyaux 2.2 et plus.
Si vous n'avez que deux ports série, ttyS0 et ttyS1, cela fonctionne encore puisque les conflits de partage d'IRQ n'existent pas pour des périphériques non existants.
Si vous ajoutez un modem interne et gardez ttyS0 et ttyS1, vous devriez alors tenter de trouver une IRQ non utilisée et la positionner à la fois sur votre port série (ou carte modem) et ensuite utiliser setserial pour l'assigner à votre pilote de périphérique. Si l'IRQ 5 n'est pas utilisée par une carte son, ce peut être une IRQ utilisable pour un modem. Pour positionner l'IRQ de manière matérielle vous devrez peut-être utiliser isapnp, un BIOS PnP ou modifier Linux pour le rendre PnP. Pour vous aider à déterminer quelles IRQs sont disponibles, tapez "man setserial" et cherchez, disons "IRQ 11".
stty effectue la plupart de la configuration du port série mais puisque
les applications (et le programme getty) la gèrent souvent, vous n'aurez
peut-être pas besoin de l'utiliser souvent. C'est pratique si vous avez des
problèmes ou voulez voir comment le port est paramétré. Essayez de taper
``stty -a'' sur votre terminal/console pour voir les paramètres actuels.
Essayez aussi de taper la commande sans le -a (all = tout) pour obtenir une
liste courte qui montre les paramètres différents de la normale. N'essayez
pas d'apprendre tous les réglages à moins de vouloir devenir un gourou du
port série. La plupart des valeurs par défaut conviennent et certains
réglages ne sont nécessaires que pour certains terminaux non-intelligents et
obsolètes fabriqués dans les années 1970 (Mais pas après)
Alors que setserial ne travaille qu'avec les ports série réels, stty
s'utilise à la fois pour les ports série et pour les terminaux virtuels comme
l'interface texte standard de Linux sur un moniteur de PC. Pour le moniteur
de PC, la plupart des paramètres de stty n'ont pas de signification. Le
changement de la vitesse de transmission, etc. ne semble pas faire grand
chose.
Voici quelques uns des items que stty peut configurer : vitesse
(bits/seconde), parité, bits par octet, nombre de bits de stop, enlever
le 8ème bit ?, signaux de contrôle du modem, contrôle de flux, signal
d'arrêt, délimiteurs de fin de ligne, changer la casse, remplissage, sonner
si le tampon déborde ?, écho, permettre à des tâches de fond d'écrire sur le
terminal ?, définir des caractères spéciaux (de contrôle, comme quelle touche
presser pour faire une interruption). Voyez la page de manuel de stty
ou la page info pour plus de détails. Voyez aussi la page de manuel :
termios qui couvre les mêmes options que stty mais (en mi-1999) couvre
des possibilités que la page de manuel de stty ne mentionne pas. Pour
l'utilisation de certains caractères spéciaux, voyez
caractères spéciaux (de contrôle).
Avec certaines implémentations de getty (paquet getty_ps), les commandes qu'on enverrait normalement à stty sont entrées dans un fichier de configuration getty : /etc/gettydefs. Même sans ce fichier de configuration, la ligne de commande de getty devrait suffire pour paramètrer les choses de sorte que vous n'ayez pas besoin de stty.
On peut écrire des programmes en C qui modifient la configuration de stty etc. Regarder la documentation pour ce faire peut aider quelqu'un à mieux comprendre l'utilisation des commandes stty (et ses nombreux arguments possibles). Le Serial-Programming-HOWTO est utile. La page de manuel de termios contient la description de la structure au sens langage C (de type termios) qui stocke la configuration de stty dans la mémoire de l'ordinateur. Bien des noms de drapeaux dans cette structure C sont quasiment les mêmes (et font la même chose) que les arguments de la commande stty.
L'utilisation de stty pour inspecter ou configurer le terminal que vous
utilisez est facile. Faire ca pour terminal (étranger) different ou un port
série est délicat. Par exemple, supposons que êtes sur le moniteur du
PC (tty1) et vouliez utiliser stty pour le port série ttyS2. Vous devez
utiliser l'opérateur de redirection <. D'abord, soyez prévenu que s'il y a
un terminal sur ttyS2 et un shell tourne sur ce terminal, ce que vous verrez
alors sera décevant et une tentative de le paramétrer sera infructueuse.
Voyez
deux interfaces sur un terminal
pour comprendre ceci.
Tapez ``stty -a < /dev/ttyS2'' pour regarder les paramètres de ttyS2. Utilisez le même opérateur de redirection < pour paramétrer ttyS2. Cela fait de ttyS2 l'entrée standard de stty. Ca donne au programme stty un lien vers le "fichier" ttyS2 donc il doit le "lire". Mais au lieu de lire les octets envoyés vers ttyS2 comme on pourrait le prévoir, il utilise le lien pour trouver les paramètres de configuration du port donc il devrait les lire ou les changer. Certaines personnes tentent d'utiliser ``stty ... > /dev/ttyS2'' pour paramétrer le terminal. Ceci ne le fera pas. À la place, il prendra le message normal affiché par la commande stty pour le terminal sur lequel vous êtes (tty1) et envoie ce message à ttyS2 mais ne change aucun paramètre pour ttyS2.
Arrive un autre problème avec l'opérateur de redirection. Quelques fois quand on essaye d'utiliser stty, la commande s'arrette et rien ne se passe ( vous n'avez pas de prompt pour une autre commande, même après avoir frapper <entrée>). C'est probablement due au port étant bloqué car il attend une ligne de controle modem pour être déclaré. Par exemple, tant que vous n'avez pas parametrer "clocal" pour ignorer les lignes de controles modem, Alors si il n'y a pas de signal CD de déclaré, le port ne s'ouvrira pas et stty ne fonctionnera pas. Une situation similaire doit exister pour le control de flux materiel. Si le cable du port n'a pas de fils pour la broche qui doit être déclaré donc il n'y a pas besoin d'arreter l'attente.
Une façon à essayer pour se passer de cette attente, est d'utiliser un programme sur le port qui le forcera à être opérationnel même si les lignes de controles disent le contraire. Ainsi heureusement, ce programme doit parametrer le port donc il n'a plus besoin du signal de controle pour ouvrir: clocal ou -crtscts. Pour se servir de "minicom" pour faire ca, il faut le reconfigurer pour un autre ttyS, etc, et le redémarrer. Puisque vous avez à reconfigurer minicom, c'est plus simple de redémarrer le PC.
Les versions à partir de 1.17 (pas encore sortie en mi-1999) n'auront plus besoin de la redirection (<) mais à la place utiliseront ``stty ... -F /dev/ttyS2'' (ou --file au lieu de -F), etc. Cela devrait forcer le port à s'ouvrir et eviter le second problème de redirection.
En utilisant un shell (tel que bash) avec l'édition de la ligne de commande activée, il y a deux interfaces de terminal différentes (ce que vous voyez quand vous tapez stty -a). Quand vous tapez sur la ligne de commande vous avez une interface "brute" temporaire (mode brut, ou "raw") où chaque caractère est lu par l'éditeur de ligne de commande au moment où vous le tapez. Une fois que vous appuyez sur la touche <entrée>, l'éditeur de ligne de commande sort et l'interface du terminal est modifiée en interface nominale "améliorée" (mode amélioré ou "cooked") pour le terminal. Ce mode amélioré dure jusqu'à ce que l'invite suivante soit envoyée au terminal. Notez qu'on ne tape jamais rien dans ce mode "amélioré" mais ce qui a été tapé en mode raw passe en mode amélioré dès qu'on a tapé sur la touche <entrée>.
Quand une invite est envoyée au terminal, le terminal passe du mode "amélioré" au mode "brut" (comme il le fait quand vous démarrez un éditeur puisque vous démarrez l'éditeur de ligne de commande). Les paramètres pour le mode "brut" ne sont basés que sur les paramètres de base pris à partir du mode "amélioré". Le mode brut garde ces paramètres mais modifie plusieurs autres paramètres afin de passer en mode "brut". Il n'est pas du tout basé sur les paramètres utilisés dans le mode "brut" précédent. Ainsi si on utilise stty pour modifier les paramètres du mode brut, de tels paramètres seront perdus dès qu'on appuiera sur la touche <entrée> sur le terminal qu'on suppose avoir "configuré".
Maintenant, quand on utilise tape stty pour regarder l'interface du terminal, on peut avoir une vue soit du mode amélioré, soit du mode brut. Vous devez trouver lequel vous regardez. Si vous utilisez stty à partir d'un autre terminal pour vous occuper d'un terminal qui affiche une ligne de commande, vous aurez la vue du mode brut. Tout changement effectué ne le sera que pour le mode brut et sera perdu quand quelqu'un appuiera sur <entrée> sur le terminal que vous avez tenté de "paramétrer". Mais si vous tapez une commande stty sur votre terminal (sans utiliser < pour la redirection) et ensuite tapez sur <entrée>, c'est une histoire différente. <entrée> met le terminal en mode amélioré. Vos modifications seront sauvées et seront toujours présentes quand le terminal reviendra en mode brut (sauf, bien sûr, si c'est un paramètre non permis en mode brut).
Cette situation peut créer des problèmes. Par exemple, supposez que vous corrompez votre interface de terminal et que pour la récupérer vous alliez sur un autre terminal et tapiez "stty sane <dev/ttyS1" pour la récupérer. Ceci ne fonctionnera pas ! Bien sûr vous pouvez essayer de taper "stty sane ..." sur le terminal corrompu mais vous ne pouvez pas voir ce qui est tapé. Tout ce qui précède ne s'applique pas aux terminaux non-intelligents mais aux terminaux virtuels utilisés sur un moniteur de PC ainsi que sur les terminaux fenêtrés sous X. En d'autres termes, ceci s'applique à presque tout le monde qui utilise Linux. Heureusement, un fichier qui lance stty au démarrage s'occupera certainement d'un terminal (ou d'un port série sans terminal) n'ayant aucun shell tournant dessus, donc il n'y a pas de problème.
Si vous avez besoin que stty configure l'interface série à chaque fois
que l'ordinateur démarre, vous devez mettre la commande stty dans un
fichier qui sera exécuté à chaque démarrage de l'ordinateur (de Linux). Il
devrait être lancé avant l'utilisation du port série (ce qui comprend le
lancement de getty sur le port). Il y a de nombreux endroits disponibles pour
le mettre. S'il est mis à plus d'un endroit et que vous n'en connaissez (ou
rappelez) qu'un, il y aura sûrement un conflit. Assurez-vous donc de
documenter ce que vous faites.
Un bon endroit pour placer cette commande serait dans le même fichier qui lance setserial quand le système démarre. L'emplacement dépend des distributions et des versions. Il semblerait mieux de la placer après la commande setserial pour que la partie de bas niveau soit faite en premier. Si vous avez un répertoire dans le /etc où tous les fichiers sont éxecutés au démarrage (System V Init), ainsi vous pourriez créer un fichier nommé "stty" dans ce but.
Voyez Terminfo et Termcap (en détails) pour une discussion plus détaillée sur terminfo. Beaucoup d'applications que vous lancez utilisent la base de données terminfo (anciennement termcap). Celle-ci possède une entrée (ou fichier) pour chaque modèle ou type (tel que le vt100) de terminal et indique ce que le terminal peut faire, quels codes envoyer pour diverses actions, et quels codes envoyer au terminal pour l'initialiser.
Puisque beaucoup de terminaux (et de PC aussi) peuvent émuler d'autres terminaux et possèdent des "modes" d'opération variés, il peut y avoir plusieurs entrées terminfo parmi lesquelles choisir pour un terminal physique donné. Ils auront en général des noms similaires. Le dernier paramètre de getty (à la fois pour agetty et getty_ps) devrait être le nom terminfo du terminal (ou de l'émulation de terminal) que vous utilisez (comme vt100).
La base terminfo fait plus que simplement spécifier de quoi le terminal est capable et de donner les codes à envoyer au terminal pour le faire faire certaines choses. Elle spécifie à quoi "gras" ressemblera (sera-ce en vidéo inverse ou en intensité forte), comment sera le curseur, si les lettres seront noires, blanches ou d'une autre couleur, etc. En terminologie PC on appelle ceci des "préférences". Elle spécifie les codes d'initialisation à envoyer au terminal (analogues aux chaînes d'initialisation qu'on envoie aux modems). Linux n'envoie pas automatiquement de telles chaînes au terminal. Voyez chaîne d'initialisation. Si vous n'aimez pas l'affichage à l'écran ni son comportement, vous devrez peut-être éditer (et ensuite mettre à jour) le fichier terminfo (ou termcap). Voyez compilateur terminfo (tic) sur la manière de faire la mise à jour.
Voici deux variables d'environnement pour les terminaux : TERM et TERMINFO, mais vous ne devriez rien avoir à faire avec elles. TERM doit toujours être positionnée au nom du terminal que vous utilisez (comme vt100). Si vous ne connaissez pas son type (nom), voyez quel est le nom terminfo de mon terminal ?. TERMINFO contient le chemin vers la base de données terminfo, mais peut ne pas être nécessaire si la base de données est dans un endroit prédéfini (ou TERMINFO peut être positionné automatiquement par un fichier qui est livré avec votre distribution de Linux). Vous voudrez voir Emplacement des bases de données compilées.
Heureusement, le programme getty positionne en général TERM pour vous juste avant le login. Il utilise juste le type de terminal qui a été spécifié sur la ligne de commande de getty (dans /etc/inittab). Cela permet aux applications de trouver le nom de votre terminal et ensuite de regarder les capacités du terminal dans la base de données terminfo. Voyez variable TERM pour plus de détails sur TERM.
Si votre base de données terminfo ne peut pas être trouvée, vous verrez un message d'erreur à ce propos sur votre terminal. Si cela arrive il est temps de vérifier où réside terminfo et de positionner TERMINFO si nécessaire. Vous pouvez découvrir où se trouve la base de données terminfo en cherchant un fichier terminfo courant comme "vt100" avec la commande "locate". Assurez-vous que votre terminal est dans cette base de données. Un exemple de positionnement de TERMINFO : export TERMINFO=/usr/share/terminfo (mettez ceci dans /etc/profile ou autre). Si les données concernant votre terminal dans cette base de données ne vous conviennent pas, vous devrez l'éditer. Voyez terminfo et termcap (bref).
Vous avez besoin du nom exact afin de positionner la variable d'environnement
TERM ou pour renseigner getty. Le même nom doit être utilisé à la fois
par la base termcap et la base terminfo, vous n'avez donc besoin de le
trouver qu'une seule fois. Un terminal dispose généralement d'alias mais si
vous trouvez plus d'un nom, utilisez le premier.
Pour le trouver, essayez de regarder le fichier /etc/termcap... (si vous l'avez). Sinon, regardez soit dans l'arborescence terminfo (voyez ref id="tc_compiled_locs" name="emplacement des bases de données compilées">), soit essayez de trouver le fichier de code source de terminfo (voyez ref id="tc_source_loc" name="emplacements du code sources des bases de données">).
Le fichier de configuration /etc/ttytype est utilisé pour faire la correspondance entre /dev/ttySn et les noms de terminaux comme dans terminfo. tset l'utilise, mais si la variable d'environnement TERM est déjà positionnée correctement, alors ce fichier n'est pas nécessaire. Puisque le getty de Linux positionne TERM pour chaque tty, vous n'avez pas besoin de ce fichier. Dans d'autres systèmes Unix comme FreeBSD, le fichier /etc/ttys fait la correspondance entre les ttys et bien plus de choses, comme la commande getty appropriée, et la catégorie de connexion (comme "dialup"). Un exemple de ligne pour le ttytype sous Linux : vt220 ttyS1
Par défaut, l'utilisateur root ne peut pas se logger à partir d'un terminal. Pour permettre cela vous devez créer (ou éditer) le fichier /etc/securetty en suivant la page de manuel "securetty". Mais cette utilisation est spécifique à la distribution, la Suse n'utilise pas /etc/securetty. Pour restreindre les logins de certains utilisateurs et/ou de certains terminaux etc., éditez /etc/login.access (cela remplace le vieux fichier /etc/usertty ??). /etc/login.defs détermine si /etc/securetty doit être utilisé et peut être édité afin que /etc/securetty ne soit pas nécessaire (ou utilisé). /etc/porttime restreint les heures auxquelles certains ttys et utilisateurs peuvent utiliser l'ordinateur. S'il y a trop de tentatives de login ratées pour un utilisateur, cet utilisateur peut se voir interdire l'accès au système. Voyez la page de manuel "faillog" sur la manière de contrôler cela.
Il y a parfois des commandes qu'on ne veut exécuter au démarrage que pour un certain type de terminal. Faire cela pour la commande stty ne pose pas de problèmes puisque l'on utilise l'opérateur de redirection < pour spécifier le terminal vers lequel la commande est destinée. Mais quid des alias de shell ou des fonctions ? Vous aurez envie de créer une fonction pour la commande ls qui mettra en couleur la liste des répertoires uniquement sur des terminaux couleur ou sur la console. Pour les terminaux monochromes vous voudrez le même nom de fonction (mais un corps de fonction différent) qui utilisera des symboles à la place du codage par couleurs. Où mettre de telles définitions de fonctions qui doivent être différentes pour des terminaux différents ?
Vous pouvez les mettre à l'intérieur d'opérateurs "if" dans /etc/profile qui est lu au départ à chaque fois que quelqu'un se logge. L'opérateur confitionnel "if" définit certaines fonctions etc., seulement si le terminal est d'un type spécifique.
Bien que la plupart de ce que fait cet opérateur if puisse être fait dans le fichier de configuration de dircolors, voici un exemple dans le cas du shell bash :
if [ "$TERM" = linux ]; then
eval `dircolors`;
elif [ "$TERM" = vt220 ]; then
ls () { command ls -F $* ; }
# pour exporter la fonction ls():
declare -xf ls
else echo "De /etc/profile : terminal de type $TERM inconnu"
fi