Evolution of shells in Linux (developerWorks)

I want it to work in plaing text consoles (over SSH). There are more than enough GUI file managers. Right now I'm trying to layer it over tmux, and I'm slowly making progress.

>Yes, the unix terminal system uses in-band signaling. In-band signaling has advantages and disadvantages with respect to out-of-band signaling, but in the case of the tty layer, the advantages outweigh the disadvantages, which have all been overcome.

I don't mind the idea of transmitting bytecode for drawing. I just don't like the way it works right now. It's messy, ugly, buggy and so on.

Have you ever tried to read the code of terminal emulators? Nightmares of escape sequences still plague my dreams :)

>The reason console2 doesn't use the technique you describe is that it doesn't work. Yes, you can create "child consoles" and associate processes with them, but there's no "master side" interface to these child consoles: there is no way to extract text from them, to see what your child programs are attempting to output and output it yourself in a controlled manner. Yes, you can scrape the console, but the scraping process has inherent race conditions. (And scraping is messy besides: you're complaining about terminal control codes?)

You can associate a child console with parent which would make it visible. But yes, I guess it's one week spot. As far as I remember, conman (console manager) worked around it by intercepting console layer calls by injecting a DLL into address space of child processes.

If I were to design a console layer right now, then I'd have have chosen Windows model with explicitly defined marshalling protocol.