| |||||||||||||
Evolution of shells in Linux (developerWorks)Evolution of shells in Linux (developerWorks)Posted Dec 8, 2011 21:19 UTC (Thu) by quotemstr (subscriber, #45331)In reply to: Evolution of shells in Linux (developerWorks) by Cyberax Parent article: Evolution of shells in Linux (developerWorks)
> But the console layer itself is quite robust and easy to use.
Are you on the payroll, or are you just completely unacquainted history and actual programming?
The Windows console layer has no pseudoterminals. That's why there are a dozen remote-command-invocation facilities in Windows, and it's why none of them works right. It's why Console2 fails badly when talking to some programs (e.g., cmd) --- Windows programs are forced to use pipes instead of consoles, so programs run under a console other than conhost itself don't even know they're being used interactively, resulting in various horrible issues the Unix world fixed 20 years ago.
(Log in to post comments)
Evolution of shells in Linux (developerWorks) Posted Dec 8, 2011 21:33 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
No. I'm just trying to port FAR Manager to Linux without going insane. Alas, sanity is fleeing fast so I'll soon need some of Linus' meds.
>The Windows console layer has no pseudoterminals.
It would have been OK, but terminal emulators suffer from terminal schizophrenia. They try to act as if they are line printers while at the same time trying to act as if they are driving a VT100 console. Which fails badly.
In Windows consoles are just consoles. I.e. a screen buffer on which you can draw text - and that's basically all. You can do whatever you want with it.
Instead of pseudoterms you can create child consoles (including invisible ones) and use them to start other programs. I'm not sure why console2 doesn't do it.
Evolution of shells in Linux (developerWorks) Posted Dec 8, 2011 21:44 UTC (Thu) by quotemstr (subscriber, #45331) [Link]
> No. I'm just trying to port FAR Manager to Linux without going insane.
Consider using the VTE widget from GNOME: http://developer.gnome.org/vte/0.30/
> It's essentially a channel to transmit bytecode which is executed by terminal emulator to draw text.
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. The chief advantage is being to use a terminal-agnostic channel (like a TCP connection) over which a terminal-program and a terminal-emulator can communicate. The Windows world has no equivalent because its console uses opaque out-of-band signaling.
> Which fails badly.
No, the terminal system actually works very, very well in practice.
> Instead of pseudoterms you can create child consoles (including invisible ones) and use them to start other programs. I'm not sure why console2 doesn't do it.
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?)
Evolution of shells in Linux (developerWorks) Posted Dec 8, 2011 21:54 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
>Consider using the VTE widget from GNOME: http://developer.gnome.org/vte/0.30/
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.
|
|||||||||||||