Great basic introduction imo. When I was starting out I was blindly copy pasting CLI commands from tutorial pages without any idea what was happening. Even if you limit yourself to "Frontend Development" only it is super useful to have some degree of mastery of you shell of choice. Would recommend to start out with the native terminal that comes with your OS instead of something rather heavy than electron powered Hyper.
> For Windows users, it's probably worthwhile installing the Windows's Terminal app (from Microsoft) vs using cmd.exe or powershell.exe.
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)
Yeah, GP comment is conflating command shells with terminal emulators, something a lot of Windows people seem to do (far less common among Unix/Linux/macOS/etc users)
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)
It's not surprising given how Micro$oft have treated developers over the years. Conflating terms is their specialty, now they're brainwashing a generation in order to force their opinions on us older greybeards.
FWIW my personal preference is bash+alacritty+Linux.
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.
> 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.
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.
One thing with $ in a shell prompt - $ is meant to indicate the command should be ran as a normal user, while # indicates the command should be ran as a super user.
Generally, yes. But some guides or tutorials don't respect this convention and use any number of chars including the author's own personal prompt. (I see `>` used often too).
I'm guilty of this, as I have my prompt set to a single > character. I'd be interested to know where the $ as a representation for user input suggestion originated from. I didn't know about # indicating that a command should be run as a superuser
I would always use '>' in README files to indicate the command was to be ran in a command prompt window for Windows users, usually followed with context.
“ Just about every operating system will come with a built-in terminal, like MacOS' Terminal.app, or Windows' Command Prompt. These applications work, but they're pretty underwhelming. Most developers opt to use something else.”
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?
The article is painful to read. For one thing, the author comingles the GUI terminal app with the shell, which are distinct things.
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.
You could forward all your constructive points to the author and ask for a correction. This guide will be read by many front-end developers and designers.
Does this stereotype of the front end dev who is more of a visual person and can't use a terminal even exist any more? If they do exist I've never encountered one in my 10 years as a dev. Most front end devs I've interacted with have the same background as any other developer and just prefer working in JS but would be comofortable working full stack.
20 comments
[ 3.6 ms ] story [ 60.3 ms ] threadAlso 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
In the absence of any configuration, the default prompt for most shells is (or was) simply $. When you su to root, it becomes #
https://news.ycombinator.com/item?id=31107606
https://news.ycombinator.com/item?id=31116288
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.
https://news.ycombinator.com/item?id=31094510