What to Call Windows CMD Command-Line Thingy

[orcmid]

There is the confusion over terminal, shell, and command-line as well as what to call applications that run in the command-line terminal versus elsewhere.

Figure this out and be consistent everywhere.

[orcmid]

Evidently, cmd.exe is everywhere called "Command Prompt." This reminds me of a situation where I joined a large company and one of the systems being worked on was not named for what it did (handle billing corporate wide) but for the task force that led to its definition.

"Command Prompt" is how the title bar is filled if you launch cmd.exe. It is how the tab is named in the new Windows Terminal. It is how VS2019 names its links for developer tools, such as "x64 Native Tools Command Prompt for VS 2019." If you do a desktop search for "Command Prompt" the first suggestion is for the "app" of that name. Yes, cmd.exe.

OK, this is not as screwy as making "them" and "they" singular pronouns. But it does name cmd.exe for one thing it does, not for what it is. It is also spoken of as a "shell," or as a "command-line shell." If you feel like you have stepped beyond the looking glass, welcome.

Wikipedia has this wisdom to offer. There is this wisdom: "cmd.exe interacts with the user through a command-line interface. On Windows, this interface is implemented through the Win32 console." That article provides links to Windows Console documentation and the current open-source of what seems to be conhost.exe in the Microsoft Terminal project. Because of common-code between conhost.exe, wt.exe, and conPty (don't ask), this comes out more confusing than necessary. Seems to need one more (maybe one less?) level of indirection :).

[orcmid]

I would say that "Command Prompt" is so well-established, even cross-platform, that I will honor precedent.

I am a little conflicted on whether to describe it as a "command-line interpreter" or "command-line shell." It is clear that the command lines are taken from a Windows Console instance (or Terminal tab).

I think there is a clue in how hand-offs to "character-mode" applications happen, such that they run in the same Windows Console instance (or Windows Terminal tab). And command "start" can lead to a new console instance, whether used or not, depending on the nature of the program launched.

Yes, I over-think regularly.

[orcmid]

I think I will take a look at what the 4NT (and its sequels) folk did with this. It is now called Take Command, and there is a TCC flavor too. So TCMD (cute) and TCC. Another interesting factor is the use of eWriter for their Help system. I have been a fan of Help systems and I might have to get a trial of TCC v28 just to learn about that (for docEng and maybe my own use).

And mainly, I am looking for anything that helps with the CMD nomenclature.

I used 4NT in the day. I liked it. I have foresworn it on nfoTools because I don't want to do anything that can't be done with the built-in-everywhere-on-Win32 CMD on people's computer.

[orcmid]

I found the information on eWriter and related products. I like write-once products. eWriter requires that I have a web site already. This would be a good way to preserve some of my dormant web sites before I give up the domain names though. I need to see how that can work. This is a matter for docEng though.

JP Soft does have more information. I have dig deeper for nomenclature information:

• There is identification of command-line processing/processors. Much of the talk is about the tabbed Take Command GUI and also TCC (Take Command Console) is compared with CMD and they talk about CMD, TCC, Bash, Powershell Consoles.
• This is not helpful.
• I think I favor processor as in "Command Prompt processor." I might use command-line processor.

The Microsoft Docs speak of consoles and character-mode applications. There is considerable confusion that some pictures might help with, regarding console-pseudoconsole-terminal. Then there's Virtual Terminal.

[orcmid]

Ohhh, the coin is starting to drop. Even Hanselman's compressed explanation is starting to make sense.

It seems to be all about Terminal. Now, I can't say Command Prompt Terminal. That gets the abstraction wrong.

The key thing is that there is a layer that is between a (distant) terminal and cmd.exe that provides the buffering and features that employ the buffering (which might or might not be remote to some degree). It is the layer that will provide input-line editing as if it was happening at the terminal before send/enter is pressed. Don't know about history recall, but maybe that also. What's tricky is that users interact with that and that intercepts some control actions that will never be seen by CMD (though who knows how leaky this layering is).

Some of this separation is apparent when one sets properties on a shortcut to cmd.exe. It looks like the ones about screen size, buffer size, and font choice are really about setting up conhost and are not seen by cmd.exe. Maybe.

The encouragement for apps to not use conhost but to rely on Virtual Terminal characteristics supported by Windows Terminal makes more sense. It doesn't mean conhost goes away. It means that portable character-mode apps are better served by relying on Virtual Terminal than conhost. [Virtual] Terminal is wired up on the other side of conhost in a way that all the rendering and handling of terminal character-mode actions is done at the Terminal layer (including a possible remote). conPTY features are part of how this is done maybe, but that's implementation. But conPTY is available for any other software that wants to pretend to be a terminal (and its user).

I'm inclined to use console for this hookup. Still over-thinking.

[orcmid]

There's an experiment that I need to run. I will make a character app that simply echoes its line input to the screen.

This should be something that reveals to the user that there are these layers and how they are [not] visible to the user and/or the app software.

[orcmid]

I am resolved about terminology now. I will still make the demonstrative character-mode application, #18.

So, CMD is Command Prompt. That seems to be the official terminology. I will speak of CMD command-line operation and command-line environment. The business about terminals and consoles will be dealt with separately and indirectly.

There is a historical basis for this separation and model, going back to Unix and before. It came with on-line access to multi-user systems. That is maybe a generic Note, and then maybe something specific about what a CMD command-line environment and operations with it are.