Today, Anthony Sherbondy brought up a question that also troubled me since a long time:
> For example, when I have an application running (either <doc/ > family.l> or <app/main.l> I have difficulty exiting the application, > requiring several <Control-X> and/or <Control-C> attempts to escape. > When I do finally exit and I am in terminal (bash shell) I can type > commands ("exit" for example), but I cannot see them on the screen. The good news first: I think I found a good solution! But let me first try to explain the situation. If you start up a server application with something like ./p dbg.l xxx/main.l -main -go it will sit there and wait for a browser to connect. If you hit Ctrl-C now, it will terminate, and everything will be OK. As soon as a browser connects, the server process will spawn a child process, and display the ':' prompt for interactive debugging. Because "dbg.l" was loaded, this debugging session will switch the console to "raw" mode, meaning that all character processing is now handled by picoLisp itself. This means, for example, that Ctrl-C is caught, so that it will no longer kill the whole process, but interrupt a running program in a controlled way to enter a picoLisp breakpoint. To terminate such a session, the recommended way is to type a single ENTER. This will cause the child process to exit. Before it does so, it will reset the console to the normal "cooked" mode. The server continues to run, and will accept further browser requests, but can be killed with Ctrl-C any time, because the console is in "cooked" mode again. Problems arise when you connect the browser a second time, *before* the first child process exited. Then suddenly two processes are listening on the console for key strokes, competing for user input, and it is not predictable which process will receive which key. Usually the input to both processes will be garbled. The second problem resulting from the situation of multiple processes on a single console was that hitting ENTER repeatedly would terminate all child processes, but leave the console in "raw" mode sometimes, because the order in which the child processes was not defined and could result in undesired effects. That's why I always took care to first terminate a debugging session with ENTER before re-connecting the browser, or hitting Ctrl-C to stop it all. Unfortunately, during heavy testing, I also forgot to do so from time to time and ended up with a raw console. (The usual Unix remedy to that is to type blindly "stty sane" followed by a Ctrl-J) Now, however, the situation should be greatly improved. In the new testing version (to be released as 2.3.2 at the end of this month), I just introduced two modifications: 1. The cooked/raw mode handling is changed now, so that the order of process termination should not influence the final result (a cooked console) after all processes exited. 2. The command line editor now understands Ctrl-D as a command to terminate *all* child processes (including itself). This means: - Hitting ENTER once will terminate the *current* process (as before). - Hitting ENTER repeatedly will terminate all child processes (as before), however it will *not* leave the console in raw mode any longer. - Hitting Ctrl-D will also terminate the current process, but possibly also all other siblings. This is equivalent to as many ENTER hits as there are child processes. So, the simple rule is: If you are lost on the console, and not sure what's going on, you can clean up the whole mess by typing just two key strokes Ctrl-D Ctrl-C no matter if there are zero, one or many child processes running. That's it. Cheers, Alex -- Software Lab. Alexander Burger Bahnhofstr. 24a, D-86462 Langweid [EMAIL PROTECTED], www.software-lab.de, +49 8230 5060