Re: [Bug-apl] akt (APL Keyboard Translator) version 2.0

[David B. Lamkins]

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