Je me déteste pour dire cela, mais
Il y a plus d’une façon de peler une cat.
J'entends par là entrée standard, puis entrée standard.
Ou, il y a la lecture du clavier (terminal),
et puis il y a lecture du clavier. Essayer
less < afilename
Ça marche comme
less afilename
ce qui signifie less doit avoir un moyen de lire sur le clavier
autre que la lecture de l'entrée standard.
Voici une autre commande qui fonctionne, même si vous ne vous y attendiez pas:
less afilename < /dev/null
Regarder la tty commander .
Il indique le nom du terminal (terminal) connecté à l’entrée standard.
Cela fonctionne en appelant la ttyname fonction de bibliothèque avec un argument de 0 (le descripteur de fichier de l'entrée standard).
less appelle probablement ttyname(1) pour obtenir le nom du terminal (terminal) connecté à la sortie standard.
Il ouvre ensuite ce terminal pour la lecture et accepte les commandes de celui-ci.
Il ne lit pas les commandes de l'entrée standard. c’est seulement pour les données.
Nous avons donc deux processus quasi indépendants ( cat et less ) indépendamment (simultanément) lecture du clavier
(c’est-à-dire le terminal / terminal) sur deux descripteurs de fichiers indépendants.
Cette situation est source de confusion et constitue en quelque sorte une «condition de concurrence».
Je trouve cela un peu analogue au fonctionnement d’un flipper ,
dans lequel il y a beaucoup de voies ou chemins que la balle peut prendre -
et il faut toujours un ; cela ne peut jamais prendre plus d'un. De même,
lorsque plusieurs processus lisent simultanément sur le même terminal,
chaque ligne tapée (si le terminal est en mode ligne)
ou chaque caractère saisi (si le terminal est en mode caractère)
va à exactement un processus.
Et la sélection est arbitraire, pas très différente de l'action du flipper.
Ce n’est pas complètement «aléatoire», pas plus que la planification des processus est aléatoire;
mais c’est essentiellement imprévisible.
Alors, voici ce qui se passe:
cat lit à partir de son entrée standard, qui, par défaut, est le terminal,
et écrit sur sa sortie standard, qui est le tuyau à less. - À un moment donné
less appels ttyname(1),
obtient le nom du terminal sur lequel il est allumé et l'ouvre pour le lire.
less lit un écran plein de données (c'est-à-dire 24 lignes ou autre)
de son entrée standard (le tuyau)
et l'écrit sur la sortie standard (le terminal). - Ensuite,
less émet le : invite, met le terminal en mode caractère,
et commence à lire du terminal ( ne pas de l'entrée standard).
- Nous avons donc maintenant deux processus (
cat et less )
lecture simultanée du terminal,
et le phénomène du flipper se déclenche - les personnages (et / ou les lignes)
que vous tapez allez à cat ou less, semi-aléatoirement.
Si ça va à cat, il est écrit dans le tuyau et less traite comme des données.
Si ça va à less, il est interprété comme un less commander.
Cela n’a vraiment rien à voir avec la mise en mémoire tampon.
echo a|lessil dit 'fin' à la fin, mais pas avec cat | less même quand il frappe moins, avec cat | less, quand il frappe moins, il affiche un signe deux points pour une invite. Ce qui signifie que je suppose qu'il y a plus à l'écran. comme tu dis. Je suppose que la réponse de davidgo à propos de la mise en mémoire tampon pourrait expliquer cela. BTW je remarque juste en tapantless<ENTER>il ne demande pas de stdin, il est donc intéressant que vous puissiez y accéder.