11
votes

PEXPPECT NE PEUT PAS Passer l'entrée sur 1024 caractères?

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().


5 commentaires

PEXPECT.SPOWN doit avoir un mot-clé MAXDATA par défaut défini sur 2000 , 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 , bien cela valait la peine d'essayer je suppose.


Creusez un peu plus dans le code source, je vois qu'il utilise pty et fcntl , 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 ")


3 Réponses :


5
votes

Votre problème semble être associé à MacOS, jetez un coup d'œil à macosx 10.6.7 découpe de stdin à 1024 caractères .

Il dit essentiellement que 1024 est votre limite tampon TTY.

Je ne suis pas un expert sur Mac OS, mais peut-être que d'autres peuvent vous donner plus d'informations à ce sujet.


5 commentaires

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 () , mais ne laissez pas cet avertissement vous effrayer trop: vous pouvez utiliser stdin.write < / Code> / stdout.rad , vous devez faire attention. Sur Unix vous avez Sélectionnez < / 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 (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?



1
votes

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).

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.

Vous pouvez trouver le code ici: https://github.com/tayyabt/tprocess


0 commentaires

1
votes

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)


0 commentaires