You're welcome. I hope you find it useful.
There will be another release after I figure out how to resolve an
"interesting" job-control issue.
Briefly, if you $ akt someapp and then type ^Z to suspend someapp, you'll have
open a new shell and $ kill -CONT `pidof someapp` in order to resume.
This isn't a problem for GNU APL, which ignores the TSTP signal.
If you intend to use a program that does respond to the TSTP signal (typically
bound to ^Z), such as vim, then the safest approach is to use akt to start a
shell and then start your editor from within the shell, like this:
$ akt sh
$ vim myfile.apl
For some reason, this two-step approach starts the shell with intact job
control; programs started in this shell suspend and resume as you'd expect.
You might think that passing a command to an interactive shell would avoid the
issue:
$ akt sh -c "vim myfile.apl"
It doesn't. Not only does this shell start without job control, but it seems to
actually exec() rather than fork() the editor; take a look at the processes and
you'll see that sh doesn't exist as vim's parent.
You can force the shell to remain involved by passing a command that it can't
simply exec:
$ akt sh -c ":;vim myfile.apl"
Even so, the shell in this case doesn't have job control.
I'm new to this pty stuff. I wonder whether my having used BSD's forkpty() is
causing the problem. I plan to try a rewrite using the POSIX/Linux 98 pty API
and see whether that makes a difference.
On Mon, Jul 25, 2016 at 06:57:58PM -0500, Blake McBride wrote:
Very nice!! Thank you!!!
Blake
On Sun, Jul 24, 2016 at 7:24 PM, David B. Lamkins <address@hidden> wrote:
... and it's finished! See [2]https://github.com/TieDyedDevil/akt .
I rewrote the state machine from scratch, ridding the program of quite a
few bugs and annoyances.
References:
[1] mailto:address@hidden
[2] https://github.com/TieDyedDevil/akt