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 <[1][email protected]> > 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:[email protected] > [2] https://github.com/TieDyedDevil/akt
