I'm afraid I can't find the code, but I actually did this in the distant
past and recall having some success. (I was the one who introduced Ctty to
SysProcAttr for this very purpose! :).
One thing it seems as though you're missing is you don't set
SysProcAttr.Setctty. The documentation string for that field notes that it
won't have any effect unless you also use setsid.
type SysProcAttr struct {
...
Setctty bool // Set controlling terminal to fd Ctty
(only meaningful if Setsid is set)
...
}
Did you try these things?
I do remember reading about a lot of arcane behaviour in the manpages. See
the manpages for setsid(2), credentials(7), pty(7) and be sure to
understand them in as much detail as you can.
By the way, a neat hack for finding other people who have done similar
things:
https://github.com/search?l=Go&q=SysProcAttr+ctty&type=Code&utf8=%E2%9C%93
On 22 January 2017 at 00:07, James Aguilar <aguilar.ja...@gmail.com> wrote:
> If you don't know or care about pagers and process management, you can
> stop reading now.
>
> *Background:* I have a program that compile my code each time I modify
> it. It produces logs continuously on a terminal.
>
> I'm trying to write a go program to wrap this program so that each compile
> log is opened in a pager, and so that when a new compile starts, the pager
> for the previous compile is automatically closed. Essentially, I'm trying
> to change the program from doing (pseudo-shell)
>
> while true; do
> awaitChange
> build
> end
>
> to:
>
> while true; do
> awaitChange
> kill $!
> build | less & # <--- except less should be in the foreground of the
> terminal
> to_kill=$!
> end
>
> There are wrinkles: I don't control the program that executes this loop.
> So I wrote a go program to process the input and separate it into a series
> of output buffers based on a regexp. I've gotten it to the point where I
> can start and kill less, and feed it the separated inputs.
>
> *My problem:* less is not behaving as it would if you ran it on the
> commandline. The arrow keys don't work, ^C either does nothing (on the
> first run of less) or interrupts the parent program, etc.
>
> I believe my mistake is that I am not correctly putting less into the
> foreground. I also suspect that I'm not correctly moving my go program back
> into the foreground each time I kill the child less process. I'm wondering
> if anyone knows the magical incantation that is required to make this work
> properly. My current code is here (with the compiler replaced by a random
> number generator, since it is proprietary to the company I work for). I
> have marked with TODOs the things I think are not working correctly.
>
> https://play.golang.org/p/Xv0y-Ln7aC
>
> Any ideas what I'm doing wrong here?
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
