28

I am a Mac guy who is used to Mac's Terminal. Now I am using Windows.

  • Whats the diff between those CLI options?
  • When should I use one over the other?
  • Are there more CLI options that I should consider?
  • What CLI would you use if you were a Mac person trying to adapt to Windows?

The reason I am trying to use Windows, is that I want to ensure the CLI of my Docker projects work for Windows users, that I can write files coming from my container to Windows and ensure my README files have instructions for Windows users. And basically test everything I do on Windows too, like Python.

heart.cooks.mind
  • 1,065
  • 1
  • 9
  • 22
  • 2
    As a Mac Terminal devotee, I suggest you'll be unlikely to enjoy any of the options. IMHO, `Git Bash` is not a very complete implementation and I suspect not many Windows installations have it and it only supports as far back as Windows Vista - i.e. not Windows XP. PowerShell is an awkward, overly-verbose abomination that no sane person would want to be bothered learning - I think you can run as far back as Windows 7. Command Prompt is available on pretty much all Windows versions, but has awful syntax and idiosyncrasies. I haven't put it as an answer, because it is just my opinion. YMMV. – Mark Setchell May 29 '19 at 14:29

2 Answers2

24

Git bash is bash, which is IIRC also the default shell on MacOS. It is not the default shell on Windows, although several implementations exist (CygWin, MinGW, ...).
Git is bundled with a number of POSIX (UNIX/Linux/etc.) utilities in addition to bash; in order to avoid "collisions" with similarly named Windows commands, the most common installation option is to install bash in such a way that the other POSIX commands are only available when running bash. The Git installer will create a shortcut to launch this "private" version of bash, hence "git bash".

The Windows command prompt runs the default Windows shell, CMD.EXE, which is a derivative of the old MS-DOS command shell, COMMAND.COM. It is much less capable than most POSIX shells; for example, it did not until relatively recently support an if/then/else construct, and it does not support shell functions or aliases (although there are some workarounds for these limitations).

PowerShell is more of a scripting environment. I'd compare it to Perl on UNIX/Linux systems -- much more powerful than the standard shell, but not necessarily something I'd want to use at the command line.
One thing to be aware of is that some of the nicer PowerShell features may require you to update your version of PowerShell -- the version bundled with Windows is typically a few years old. And updating PowerShell usually requires admin privilege; depending on the version, you may also need to update the .NET framework.

If I were a Mac person trying to adapt to Windows ... it depends. In the short term it would be easier to use something familiar like bash. But long term, you -- and more importantly, your potential users -- may not want to be dependent on a third party tool, especially since for Windows users that will typically present an additional learning curve.

As to which to use when ... it really depends on what you're trying to accomplish -- both in terms of technical functionality and the interface you want to present to your users. As noted above, I'd consider PowerShell more appropriate for scripting than the CLI, unless you just need to run a cmdlet (either a built-in or one you've created yourself).

David
  • 2,226
  • 32
  • 39
  • "the version bundled with Windows is typically a few years old" - Note that as of `Windows 10 version 1607 / Windows Server 2016`, the bundled version of Windows PowerShell is 5.1. It will continue to receive security updates but no new features. You do not need to upgrade to 5.1 any longer. PowerShell Core (v7.2.2 at this time of writing) can still be installed and is managed separately from the Windows-integrated PowerShell 5.1. – codewario Apr 20 '22 at 16:06
  • @Bender That may be the case. I remember that several times I found that there was some PowerShell functionality that met a current need and then discovering that I had to upgrade to from v1 to v2, v2 to v3, etc. And after v2 (I think) it seemed you needed to install some WMI or security bundle that I didn't necessarily want (and that might have red-flagged me to our IT security). – David Aug 17 '22 at 15:50
  • ... my point being that (1) the original page where I found information on the PS feature did not adequately call out that one might need to upgrade PS in order to use said feature, and (2) the PS downloads always seemed to be encumbered with a lot of extra crap. The latter is representative of an IMHO pretty persistent pattern with Microsoft software. – David Aug 17 '22 at 15:54
10

This is a high-level overview of some of the differences between the shells, not a feature by feature comparison.

CMD (Command Prompt) and PowerShell are both shells for Windows. CMD.exe was borne from COMMAND.COM, which was itself born from MS-DOS, and has some logical constructs and can run programs, process output, and do most basic tasks you would expect from a shell. It is generally considered very limited based on what other shells can do, but is not incapable if you know how to use it. However, it was never really "designed", with new features getting tacked on without a clear roadmap.

Powershell is a shell designed from the ground up with ties into .NET and has more modern language constructs built in. Microsoft designed Powershell as a replacement to CMD.exe and batch scripting, though CMD is far from being deprecated. Powershell can call directly into .NET classes, work with WMI objects natively, and has built in remoting capabilities. It is more akin to a programming or scripting language than batch scripting is. There is a much stronger community surrounding Powershell today than there is for batch scripting, and it is generally recommended to write new code in Powershell than to continue to use batch (CMD) scripting.

Powershell does feel like CMD at first. You can run programs in it and process their output, and in most cases programs will behave exactly the same whether they are run from Powershell, or from CMD. However, you will quickly notice some differences - not all variables are considered environment variables, variables are prefixed with a $ as opposed to being wrapped in %, and the Powershell pipeline is far more powerful than the CMD pipeline. Powershell is also entirely object-oriented, which is unique when compared to most other shell languages which are primarily text based.

You can read more here about why Powershell is recommended over batch scripting, and there is a good bit of history on CMD.exe and batch files as well.

Git Bash is the same bash shell you are used to on Linux and MacOS but instead compiled for Windows. It has the Git prefix with the name to indicate it was installed with Git for Windows, a packaging of git and various *nix utilities compiled for Windows for use with git. You can run sh and bash scripts in it, as well as call the Unix programs it installs with it.

The Unix utilities can generally be run in CMD or PowerShell too, but by default the installer does not add these utilities to the SYSTEM or USER PATH, as to not potentially override the same utilities the user may use in other contexts. Basically, it isolates the utilities installed with Git Bash to Git Bash.

Outside of git automation, I wouldn't recommend using Git Bash itself for anything production related, you would probably rather manage an installation of cygwin, msys2, or another Unix compatibility layer yourself in that case. But it can be a handy shell to have during development, although these days I generally prefer PowerShell over bash for Windows scripting.

codewario
  • 19,553
  • 20
  • 90
  • 159