5 ms·

Very interesting. I learned a lot. The author mentions "re-re-re-implementing" command line history as a disadvantage of using shells in a dumb terminal emulat

Very interesting. I learned a lot. The author mentions "re-re-re-implementing" command line history as a disadvantage of using shells in a dumb terminal emulator. But, with respect, I think he's wrong about that. Command line history is a valuable productivity enhancer, and tying the details of its operation to the terminal rather than the shell restricts functionality and flexibility. For example, witness the differences between git bash (mingw) and cmd on Windows. Inbuilt OS stuff should be as simple as possible. It doesn't have to be precisely /dev/tty - like, but it should be simple. Partly to avoid bloat, and partly because it's much less flexible than userland stuff. Even when RAM was worth twice its weight in gold, various UNIX shells weren't heavy. Now? not worth worrying about. I admit I came up as a UNIX user so I favor sh-like history. But still, Windows terminal history just isn't as good. (I wish it didn't deduplicate repeated commands and lose them when they're edited.)

laumars 8y ago
There was a few points the other raised which I disagreed with and that was one of them. I completely agree with you that shell history should be managed by the shell itself. I also didn't agree with the points about Console API. I mean sure, he's right that ANSI / VT escape sequences are naff, but they are the standard so we're stuck with them. However as much as I love the idea of a Console API, the fact that they only work on local host is just inexcusable. And I don't say this because "hindsight is 20/20", there was already decades of proven example that remote consoles are worth having before the console API was even written. Why they couldn't have created is a network API (ala rsh) is beyond me. But we are where we are. Some of the examples given about OOP was just plain wrong too. You can't bunch 20 years of object oriented langaues together and say "they all quickly followed". 20 years is not quick; not in real terms and most definitely not in IT terms. What surprised me the most when reading that article is that NT was originally command line driven with a GUI added for release. It's amazing just how bad the console sucks even without taking the evolution of NT into account; and now that I know NT was originally command line oriented, well I'm just shocked. If there was anything good that can be taken from the article, it's that it sounds like they are working on better terminal / shell separation which will enable developers to write better terminal emulators and better alternative shells. Plus potentially allow for a networked shell. My next request after that would be to write a unified way of splitting ARGS because their current method of passing all command line parameters as a single string is just terrible (yes, I get that's DOS legacy and impossible to change due to backwards compatibility, but isn't it about time Windows had a standard API for splitting that ARGS string so, going forward, programs can be written to split parameters in a consistent way meaning command line users know exactly when they can and cannot use quotation marks, spaces and escaped characters, etc.
- cryptonector 8y ago
  Hear hear! Terminal escapes... you know what, they may seem ridiculous, but they work with a read/write API instead of an ioctl API, and that makes all the difference. And they work with serial ports and terminals. From day 1 terminals were read/write-oriented, not ioctl-oriented, and the concept of escapes originates with the terminal vendors, not with Unix. Regarding command-line parsing, there are ways to move to a Unix-style argument array in a way that is backwards-compatible. It could just be an attribute of the executable to exec(), that it wants a proper argument vector. Shell escaping in Windows is just not-sane.
- bitcrazed 8y ago
  Hey Laumars - Console PM and author of the post here: Fair points in part, though … Remember that things like Remote Desktop obviated the pressing need for command-line --> remote command-line access for many years. RDP quickly evolved into a very efficient way of remoting the entire desktop experience, not just Command-Line - something that was particularly necessary until PowerShell started to mature due to Windows' heavy GUI tool influence (for better and worse). Don't despair though - there's a VERY interesting post coming soon on this subject, that I think you'll enjoy! ;) I summarized 20 years of history: Simula arrived in '68, Smalltalk in '72 and then, other than research efforts, relatively little until CFront/C++ around '85. After that there was a new variant of C++ or new object oriented language almost every 8-12 months ever since - ObjectBASIC, Modula-2, ObjectPascal, Delphi, Java, Python, C#, Ruby, etc. It was practically a language explosion. And, of course NT started as a command-line OS. All new OS' start that way it's the simplest UX to get running. The Windows GUI wasn't slapped on at the end though - it arrived relatively quickly since Microsoft was able to leverage much of the experience of having build Windows 3.x/9x etc. previously. Command-line args are not all passed as a single string. In Windows, args are separated by space. If you use C/C++ and others, you get argv and argc, or in C# you get an array of space separated values. Alas, when NT came along it was seen as EXTREMELY important to make it easy to run/port MS-DOS scripts and tools to encourage migration and adoption. By this time, so many tools used so many ways of specifying args and values … / vs. \ vs. - vs. none, /o=foo, /o foo, etc. … that it was practically impossible to both support backward compat while rationalizing usage. PowerShell, though, has done much to make args MUCH more consistent, self-documenting, etc. This said, yes, it'd be AWESOME if args could be rationalized and handled in a more consistent manner. Had a fascinating discussion about just this the other day. Stay tuned to our blog ;)
cryptonector 8y ago
I really don't understand why I would want the terminal to be aware of command-line history. That seems completely wrong. On Unix one can have a terminal used by a non-shell application -- what would a terminal's command-line history mean in that case?
bitcrazed 8y ago
Hey Oliver - Console PM and author of the above post here. Glad you learned lots - makes writing it worthwhile ;) I didn't mean to imply that command history is not a productivity enhancement - it absolutely IS! What I was saying was that in the absence of a system/terminal-provided command history mechanism, every shell has to implement its own. Cmd needs it. PowerShell needs it. Bash needs it. Zsh … fish … yaddayaddayadda need command-history. So if every shell (and many apps) need a command history buffer, why not provide command-history as a service from the terminal. There are MANY amazing and valuable things one could do if one could consistently log/store/serialize command-history for later replay, analysis, etc. I agree 1000% that Windows' command history is FAR from good, but I think there are some pretty awesome things we could do to make it so. Bear with us on this ;)

laumars 8y ago

There was a few points the other raised which I disagreed with and that was one of them. I completely agree with you that shell history should be managed by the shell itself. I also didn't agree with the points about Console API. I mean sure, he's right that ANSI / VT escape sequences are naff, but they are the standard so we're stuck with them. However as much as I love the idea of a Console API, the fact that they only work on local host is just inexcusable. And I don't say this because "hindsight is 20/20", there was already decades of proven example that remote consoles are worth having before the console API was even written. Why they couldn't have created is a network API (ala rsh) is beyond me. But we are where we are. Some of the examples given about OOP was just plain wrong too. You can't bunch 20 years of object oriented langaues together and say "they all quickly followed". 20 years is not quick; not in real terms and most definitely not in IT terms. What surprised me the most when reading that article is that NT was originally command line driven with a GUI added for release. It's amazing just how bad the console sucks even without taking the evolution of NT into account; and now that I know NT was originally command line oriented, well I'm just shocked. If there was anything good that can be taken from the article, it's that it sounds like they are working on better terminal / shell separation which will enable developers to write better terminal emulators and better alternative shells. Plus potentially allow for a networked shell. My next request after that would be to write a unified way of splitting ARGS because their current method of passing all command line parameters as a single string is just terrible (yes, I get that's DOS legacy and impossible to change due to backwards compatibility, but isn't it about time Windows had a standard API for splitting that ARGS string so, going forward, programs can be written to split parameters in a consistent way meaning command line users know exactly when they can and cannot use quotation marks, spaces and escaped characters, etc.

cryptonector 8y ago
Hear hear! Terminal escapes... you know what, they may seem ridiculous, but they work with a read/write API instead of an ioctl API, and that makes all the difference. And they work with serial ports and terminals. From day 1 terminals were read/write-oriented, not ioctl-oriented, and the concept of escapes originates with the terminal vendors, not with Unix. Regarding command-line parsing, there are ways to move to a Unix-style argument array in a way that is backwards-compatible. It could just be an attribute of the executable to exec(), that it wants a proper argument vector. Shell escaping in Windows is just not-sane.
bitcrazed 8y ago
Hey Laumars - Console PM and author of the post here: Fair points in part, though … Remember that things like Remote Desktop obviated the pressing need for command-line --> remote command-line access for many years. RDP quickly evolved into a very efficient way of remoting the entire desktop experience, not just Command-Line - something that was particularly necessary until PowerShell started to mature due to Windows' heavy GUI tool influence (for better and worse). Don't despair though - there's a VERY interesting post coming soon on this subject, that I think you'll enjoy! ;) I summarized 20 years of history: Simula arrived in '68, Smalltalk in '72 and then, other than research efforts, relatively little until CFront/C++ around '85. After that there was a new variant of C++ or new object oriented language almost every 8-12 months ever since - ObjectBASIC, Modula-2, ObjectPascal, Delphi, Java, Python, C#, Ruby, etc. It was practically a language explosion. And, of course NT started as a command-line OS. All new OS' start that way it's the simplest UX to get running. The Windows GUI wasn't slapped on at the end though - it arrived relatively quickly since Microsoft was able to leverage much of the experience of having build Windows 3.x/9x etc. previously. Command-line args are not all passed as a single string. In Windows, args are separated by space. If you use C/C++ and others, you get argv and argc, or in C# you get an array of space separated values. Alas, when NT came along it was seen as EXTREMELY important to make it easy to run/port MS-DOS scripts and tools to encourage migration and adoption. By this time, so many tools used so many ways of specifying args and values … / vs. \ vs. - vs. none, /o=foo, /o foo, etc. … that it was practically impossible to both support backward compat while rationalizing usage. PowerShell, though, has done much to make args MUCH more consistent, self-documenting, etc. This said, yes, it'd be AWESOME if args could be rationalized and handled in a more consistent manner. Had a fascinating discussion about just this the other day. Stay tuned to our blog ;)

cryptonector 8y ago

I really don't understand why I would want the terminal to be aware of command-line history. That seems completely wrong. On Unix one can have a terminal used by a non-shell application -- what would a terminal's command-line history mean in that case?

bitcrazed 8y ago

Hey Oliver - Console PM and author of the above post here. Glad you learned lots - makes writing it worthwhile ;) I didn't mean to imply that command history is not a productivity enhancement - it absolutely IS! What I was saying was that in the absence of a system/terminal-provided command history mechanism, every shell has to implement its own. Cmd needs it. PowerShell needs it. Bash needs it. Zsh … fish … yaddayaddayadda need command-history. So if every shell (and many apps) need a command history buffer, why not provide command-history as a service from the terminal. There are MANY amazing and valuable things one could do if one could consistently log/store/serialize command-history for later replay, analysis, etc. I agree 1000% that Windows' command history is FAR from good, but I think there are some pretty awesome things we could do to make it so. Bear with us on this ;)