Michael Hava <mfh@live.at> 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.