[reader] unable to read from pty after Expect call about expect HOT 5 CLOSED

I'll read James Harrs version when I have some time but I never intended reads to be shared between Expect and someone else. I'll update the documentation to show this.

I based my design on the original Expect from the 1990s version that I used to use a lot back then which also required all reads to go through it. At least in that version that was no way to take over reading. I seem to recall later versions added a call to do it but it wasn't something I ever used or needed hence my simple version

As you suggest I would have written it with a 2nd expect to process the response from the login and in the fail case use exp.BufStr() to see everything that had been read:

package main

import (
"fmt"
"log"
"regexp"

    "github.com/leemcloughlin/expect"

)

func main() {
expect.Debug = true
exp, cmd, err := expect.NewExpectProc("./batch_mock.py")
if err != nil {
log.Fatalf("NewExpectProc failed %s", err)
}
exp.SetTimeoutSecs(5)

    i, _, err := exp.Expect(regexp.MustCompile(`^\s*username: >> $`))
    if i == 0 {
            exp.Send("This is a username\r")
    } else {
            log.Fatalf("failed %s", err)
    }

// NEW BIT
i, found, err := exp.Expect(regexp.MustCompile(`.*}`))
if i == 0 {
    fmt.Println("found", string(found))
} else {
    fmt.Println("failed ", err)
    fmt.Println("buffer contains: ", exp.BufStr())
}

    if err = cmd.Wait(); err != nil {
            fmt.Println("cmd error", err)
    }

}

from expect.

Thank you for the explanation. I have some recollection of libexpect, but my knowledge of that library is not as deep. The example I took this from uses exp_expectl(fd, ...) and is able to read stdout/stderr from fd until EOF.

I will think through this example. I am still unable to specify wildcards that say "simply consume everything until EOF". Regular expressions like (?m).*$ or (?m).*\z fail since the regular expression's viewpoint is limited to the local view of the bytes.Buffer, but not the end of the stream.

It may be that what I am trying to get out of the package is not compatible with what you designed it for. Or maybe what I am looking for would also be of interest to you? In short, this is:

• the ability to wait on the command an examine its exit status (#1, important for concurrent use),
• being able to pass in a cancellation context,
• uniform use of strings to specify matches (they are always compiled to regexps, since an exact string match is just a special case of regexp),
• being able to drain the read buffer (the above).

from expect.

You can now Wait on the process with NewExpectProc.

Contexts - still unsure especially after reading this in their documentation: "Do not store Contexts inside a struct type; instead, pass a Context explicitly to each function that needs it." But to me it only makes sense the way you did it in your fork. I need to spend more time working with contexts before I can decide how, if at all, to add them in.

I like that I can pass strings or regexps. I prefer to compile regexps myself so I can spot errors. Especially where I'm dynamically creating the regexp. But I could add another version of Expect that takes just regexps as strings.

If all you need is to grab all input till EOF or timeout then:
// maybe add: exp.SetTimeout(something)
exp.Expect()
fmt.Println("buffer contains: ", exp.BufStr())

from expect.

I will work with this a while, to understand the package better; I think I did not understand well enough where it is coming from.

With regard to context, the blog is old. In many places it makes sense to pass a context as first argument, examples are e.g. net/dial, or ctxhttp (an older package).

However, in newer packages, people do store context in structs, as e.g. os/exec or net/http.

One particular recent example I found useful is sync/ErrGroup which simplifies running multiple task-goroutines in parallel. Using errgroup with context makes it possible to tear down all other concurrent goroutines at the instant one of the goroutines fails.

from expect.

Thanks for the explanations. I have a couple of examples, since initially I found it difficult to understand what the package is doing. Will submit a PR with these.

from expect.