Re: [boost] Is there interest in a reusable stream-based console?

Subject: Re: [boost] Is there interest in a reusable stream-based console?
From: Anthony Foiani (tkil_at_[hidden])
Date: 2012-03-09 16:09:43

Michael Hava <mfh_at_[hidden]> writes:

> I've never before heard about GNU Readline; does that mean that
> consoles like bash don't offer such a functionality to programs
> automatically (something that even cmd.exe does)?

Remember that 'bash' isn't a "console": it's a shell, which is really
just another program that has a standard input, a standard output, and
a standard error.

Unix evolved a very clean separation of responsibilities regarding
terminal devices:

1. raw tty - character input/output
2. line discipline - xon/xoff, crlf handling, etc
3. application

In the case of a shell like 'bash', it's bash that provides command
line editing and history -- but once another program has been invoked,
that other program is fully responsible for all application-level
editing, history, rendering, etc.

The readline library (and a few others that have sprung up due to the
fact that readline is GPL'd) can be linked to any application (bash,
gplot, whatever) to provide for history, editing, completion, etc.
I'm using the BSD EditLine library ("libedit") in my application right
now, and it's working quite well.

In contrast, the command.com / cmd.exe environments are a bit of a
mishmash, and while they might provide the history services to
programs you run on the command line, I don't know if they make it
possible for each command to keep its own history, provide its own
completions, etc.  (Command.com and cmd.exe also fail to provide other
features that unix programmers take for granted, e.g., filename
wildcard / globbing.)

Finally, remember that Unix "grew up" dealing with many different
terminal output devices; the earliest didn't have screens at all, let
alone the ability to move a cursor backwards and replace existing
text.  After that, there was a period when there were a large variety
of different serial terminals, each with their own commands to
position cursor, change color, etc.  This begat another abstraction
layer (curses, terminfo, etc).

The combination of that last layer, however, together with the tty /
line discipline / application stack described above, allows the exact
same application to run over network login sessions (telnet, rlogin),
secure sessions (ssh), usb serial, and regular serial.  Cmd.exe fails
in almost all of those situations, which is why "remote
administration" of a windows server usually means "remote graphical
desktop"...

In short, you can't rely only on experiences with cmd.exe.