Je passe actuellement une entrée dans un processus avec PEXPPECT avec le code suivant:
p = pexpect.spawn('cat', timeout=5.0 ) p.maxread = 5000 p.setecho(False) INPUT_LEN = 1024 p.send('a'*1000) p.sendline('a'*(INPUT_LEN-1000)) print p.readline() # pexpect.TIMEOUT: Timeout exceeded in read_nonblocking().
3 Réponses :
Votre problème semble être associé à MacOS, jetez un coup d'œil à macosx 10.6.7 découpe de stdin à 1024 caractères forts> . p>
Il dit essentiellement que 1024 est votre limite tampon TTY. P>
Je ne suis pas un expert sur Mac OS, mais peut-être que d'autres peuvent vous donner plus d'informations à ce sujet. P>
Des recommandations sur la manière de contourner cela au niveau du python? par exemple. En écrivant 1023 octets, rincer les tampons, puis écrit le reste?
@TBA: D'après ce que vous expliquez que le problème semble être sur le côté de la lecture. Je pense donc que vous êtes pile avec une approche de tuyau (comme celui que PBPAte a), mais je crains que cela annule probablement vos efforts d'utilisation de PEXPPECT.
Malheureusement, l'utilisation de tuyaux avec «Subprocess» de Python provoque des impacts: voir «AVERTISSEMENT:» À propos de «.stdin.write» sur docs.python.org/library/subprocess.html . La solution de contournement suggérée est d'utiliser Communicate (), qui attend le processus de résiliation. Cela ne fonctionnera pas pour moi car je dois envoyer et recevoir des informations avec le processus plusieurs fois avant de se terminer.
@TBA: Si vous avez besoin d'envoyer / recevie, n'utilisez pas communiquer () code>, mais ne laissez pas cet avertissement vous effrayer trop: vous pouvez utiliser
stdin.write < / Code> /
stdout.rad code>, vous devez faire attention. Sur Unix i> vous avez
Sélectionnez CODE> < / a> (jetez un coup d'œil à Cette réponse ), tandis que pour une solution de plate-forme croix (AKA Windows TOO < / i>) Vous devrez utiliser
threads code> (jetez un coup d'œil à Cette autre réponse ).
Merci rik. J'ai déjà essayé stdin.write et STDIN.Read, mais j'ai rencontré des blocages, d'où le commutateur à PEXPECT. Avez-vous une idée de déboguer les impasses?
Je me rends compte qu'il est très très tard, mais je pose une solution à une solution pour quelqu'un qui trébuche sur cette question avec le même problème (comme je l'ai fait plus tôt aujourd'hui). p>
Basé sur certaines des réponses / commentaires, j'ai écrit un pexpect comme un package qui utilise stdin.write et stdout.read au lieu de tout ce qu'il est que le PEXPECT utilise. Je n'ai pas eu la chance de tester cela serait très approfondi, mais à ce moment-là, il s'est étendu au défi. p>
Vous pouvez trouver le code ici: https://github.com/tayyabt/tprocess p>
Dans mon cas (Debian Linux) La limite (4096 caractères) était liée au mode d'entrée de traitement canonique du terminal. Il y a quelques commentaires à ce sujet dans le Documentation PEXPECT A>. J'ai résolu mon problème en désactivant le mode Canon avant d'envoyer mes données: P> p.sendline('stty -icanon')
p.sendline('a'*5000)
PEXPECT.SPOWN CODE> doit avoir un mot-clé
MAXDATA CODE> par défaut défini sur
2000 code>, donc cela ne s'applique probablement pas à votre cas, mais avez-vous essayé de l'augmenter ?
Malheureusement cela n'a pas fonctionné; Voir la dernière modification
Désolé pour la confusion, j'ai écrit maxdata mais je voulais dire
maxiread code>, bien cela valait la peine d'essayer je suppose.
Creusez un peu plus dans le code source, je vois qu'il utilise
pty code> et
fcntl code>, cette racine de votre limite tampon 1024. Pourriez-vous fournir une version et une plate-forme Python?
La version Python est "Python 2.7" et la plate-forme est OSX 10.6.8 ("Darwin TBA.Local 10.8.0 Darwin Kernel Version 10.8.0: Tue 7 16:33:36 PDT 2011; ROOT: XNU-1504.15.3 ~ 1 / version_I386 I386 ")