The Front-End Developer's Guide to the Terminal
joshwcomeau.com
joshwcomeau.com
I have no comment on Windows, but anyone on MacOS who would find this guide to be useful would have absolutely no need to use anything other than the built-in Terminal. The guide does not say why the Terminal is underwhelming. What features does it lack, and more specifically, what features does it lack that a reader of this guide would actually need, when the reader of this guide doesn’t even know what a prompt is?
A GUI terminal doesn't need to run a shell, even if often it does.
e.g. "xterm -e emacs", now the GUI terminal is running emacs, not any shell.
(Of course arguably emacs is a shell and a universe onto itself but different topic.)
And a shell is called a "shell", not a "shell language". Yes a shell can be used as a scripting language, but when used interactively it is called a shell.
In the absence of any configuration, the default prompt for most shells is (or was) simply $. When you su to root, it becomes #
Also recommended https://explainshell.com/ to find out whats actually going on.
For Windows users, it's probably worthwhile installing the Windows's Terminal app (from Microsoft) vs using cmd.exe or powershell.exe.
cmd.exe's age shows - it's well and good for short things and short scripts, but not anything bigger imho.
powershell.exe takes up to minutes to start on some machines (I timed it while working at a repair shop).
Windows Terminal I've not used personally, but have heard a lot of good about. Another good option is using PuTTY if you're sshing into another box.
While the windows terminal is pretty useful, it is not a command shell; you still have to use a shell with it (like Cmd, PowerShell, or one of the many Linux shell ports or WSL)
cmd.exe isn’t a terminal, it is a program that talks to the terminal. People who talk about it as if it is one probably actually mean the classic Windows console system (conhost.exe/etc)
I mostly left terminology the same as in the comment I was replying to, as I didn't want to muddy the waters further for those who are just starting out (in the "I don't even know how to access the terminal!" stage). Presumably whoever is helping get them running will help them access whichever shell they need, their options will be with what terminal emulator to use.
Edit: Also, while cmd.exe and powershell.exe are shells, I was referring to the graphical programs that launch by default if you run those shells from the Windows Start menu. This may be imprecise, but it is Microsoft we're talking about here.
All cmd.exe does (and powershell.exe too), is have IMAGE_SUBSYSTEM_WINDOWS_CUI as the value of Subsystem field of its EXE's IMAGE_OPTIONAL_HEADER (which despite its name, is actually mandatory for PE EXE files.) By contrast, graphical Windows applications have IMAGE_SUBSYSTEM_WINDOWS_GUI as the value of that field. What type of terminal emulator gets launched is not determined by the EXE at all, which has no say – rather, during the process of loading/starting a IMAGE_SUBSYSTEM_WINDOWS_CUI EXE, Windows automatically launches an instance of CONHOST.EXE (unless the parent process already had a console, in which case the process will talk to its parent's instance of that process instead of a new instance), and CONHOST.EXE is what displays that window. For a long time, that UI was hardcoded – Microsoft hardcoded the executable name CONHOST.EXE into the Windows source code and didn't provide any API to run an alternative UI instead. [0] However, now in Windows 11 (and I think some late builds of Windows 10???), there are actually registry keys [1] which enable you to specify an alternative terminal UI to display, and a settings UI to enable end-users to update those registry keys. CONHOST.EXE is still hardcoded to run, but at startup it checks those registry keys, which contain the GUIDs of COM servers to delegate its functionality to, and so if specified, CONHOST.EXE will start those COM servers and delegate all its functions to them, including the display of the UI. Windows 11 still has the legacy CONHOST.EXE as the out-of-the-box default for this setting, but it is easy to change it to the new Windows Terminal app, or any third-party app you've installed (provided that app registers the necessary COM servers)–Microsoft has announced that, in a future Windows 11 update, the default value for this setting will change from legacy CONHOST.EXE to Windows Terminal.
[0] Actually, CONHOST.EXE was only introduced in Windows 7; prior Windows NT family versions, the UI code was inside CSRSS.EXE, which is a critical system process; Windows 7 split this functionality out into CONHOST.EXE instead. Unlike the Windows NT, Windows 9x/Me displayed Win32 console apps in an MS-DOS window, with an MS-DOS app CONAGENT.EXE and a VXD called VCOND used to proxy input/output between the DOS emulator and the Win32 app. Windows 3.x had no concept of Windows console apps at all – console apps were DOS apps and all Windows apps were GUI apps.
[1] See https://github.com/microsoft/terminal/blob/main/doc/specs/%2... for details