Terminal bells when sending long lines

[aidanhs]

Terminal bells when sending long lines

[jquast]

Thank you very much for the reproducable issue, this may be formed into a test case.

I'm not convinced it is unavoidable gotchya. may be a bug, marking as such for now. otherwise the fix will be documentation.

[aidanhs]

Its definitely avoidable, pexpect just needs to (if my suspicion of cause is correct) identify the pipe buffer size and flush before it hits that (with sendeof).

This would also require a some documentation fixes though because I seem to remember an implication that pexpect only flushes on newline or sendeof.

Even if pexpect doesn't do it automatically, auto flushing would be a cool feature to have.

[aidanhs]

To clarify: "even if pexpect does not have it enabled by default, it would be a nice option to have".

[aidanhs]

For my own reference, http://unix.stackexchange.com/questions/11946/how-big-is-the-pipe-buffer

[jquast]

There isn't much we can do here, if we tried to batch calls to sendline() that were larger than an arbitrary length, we're assuming whatever child process you're sending to would be ok with that, base64(1) is, but others are not. If you were using bash(1) directly with a really huge command-line, you would know that you have to break it with lines ending '\', for example.

I think if you were using base64(1) you would understand that you should batch chunks to sendline:

chunk=80
X='X'*10000
map(c.sendline, [X[start:start+chunk] for start in range(0, len(X), chunk)]

[aidanhs]

Hmm, but you don't actually need to split it up into sendlines right?
As I note (hidden away, admittedly) - "If, in batching mode, you replace sendline with a send then sendeof it also works."

This is because the sendeof flushes the buffer (I think?).
So if pexpect counted the number of characters it has sent and flushes via sendeof automatically I think it would work.

[jquast]

sendeof just sends the equivalent of ctrl+d. I wouldn't want to send that arbitrarily, but maybe we can flush the file descriptors, I'll try for a test

[aidanhs]

Thanks.
Am happy with it just being a doc fix if it comes down to it.

[jquast]

The BEL (\x07) is your terminal driver speaking -- you've reached the maximum input line for canonical input processing. Executing stty -icanon will disable canonical input, and allow you to exceed PC_MAX_CANON. Proof by test case follows:

    def test_max_canon(self):
        " BEL is sent by terminal driver when MAX_CANON is reached. "
        p = pexpect.spawn('cat', echo=False, timeout=3)
        p.sendline('_' * (os.fpathconf(p.child_fd, 'PC_MAX_CANON') - 1))
        with self.assertRaises(pexpect.TIMEOUT):
            p.expect('\a', timeout=1)
        p.sendline('_' * (os.fpathconf(p.child_fd, 'PC_MAX_CANON')))
        p.expect('\a', timeout=1)

    def test_max_no_icanon(self):
        " MAX_CANON may be exceed if canonical mode is disabled for input. "
        p = pexpect.spawn('bash', echo=False, timeout=3)
        # disable canonical mode processing of input,
        p.sendline('stty -icanon')
        p.sendline('cat')
        p.sendline('_' * (os.fpathconf(p.child_fd, 'PC_MAX_CANON') + 1))
        with self.assertRaises(pexpect.TIMEOUT):
            p.expect('\a', timeout=1)

I'll add a docstring to sendline.

[aidanhs]

Oh interesting, so nothing to do with pipe buffers whatsoever. I learn new things every day.

[jquast]

Now that I've got a SunOS, MacOSX, and Linux build slave up I've been able to refine the tests and documentation regarding MAX_CANON, Pull request #79 will close this issue. Thanks.

[takluyver]

Closed by #79.