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.
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).
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.
I have searched the web for long time without success. How can I add a new command to the kernel command line? e.g. a command like ver without any arguments, that simply prints Hello World message when executed.
The Linux kernel does not handle any commands (but the GRUB bootloader can pass some arguments to the booted kernel). It is just handling system calls. You could add some new one, but learn about advanced linux programming & syscalls(2) before hacking the kernel.
Perhaps you want to add a new command available to your shell. This is quite simple, put a new executable file (either an ELF executable, e.g. compiled from C code, or some script) in a directory known to your PATH. You might also make a new shell function.
The system call to create a new process is fork(2) (sometimes emulated thru some appropriate call to clone(2)...). fork is difficult to understand, so take several hours to read about it. Almost every process (with a few exceptions, notably /sbin/init) is created by fork. The system call to execute a new program is execve(2). Your shell will often use fork & execve to run commands (except builtin ones, like cd). Use strace(1) to understand what syscalls are done (by some program).
PS. Don't dare hacking your kernel before understanding quite well user-land Linux system programming....
I need to write a small script that renames some files in a directory. This script needs to be run on Mac and Windows.
What is the best scripting language for this? I want to write something that runs just by calling it and there is no need to install anything else.
For example, writing a Perl script and compiling it to run on Windows and then compiling it to run on Mac. Can I do this?
Any other, more elegant solution?
Nothing matches your criteria. You will need to install something (e.g. perl) if you want something that runs on both systems.
If you had perl on both systems, you could indeed write a program that runs on both. You wouldn't even need two binaries as you suggest since Perl programs are distributed as source. (perl compiles them when it loads them, and even then, they are compiled to the same form on all systems.)
I am from Unix programming background and am facing a unique behavior/problem during porting my system from Unix to Windows.
[I am pretty new to development on windows, so the below question may look too obvious.]
I am porting using mingw and the problem in question is regarding "system()" call provided in Unix and the WEXITSTATUS option.
Question
In Unix, to execute any commands/scripts we have code that uses system() call. The same compiles in mingw - but I want to know if there are any change in behavior between the Unix and Windows version of system() call.
The windows version of system() call is provided in stdlib of mingw, but am not able to get the exact behavior.
My second question is regarding WEXITSTATUS. Generally, In Unix this is used along with system() command to get the status of the command executed.
a. Can the same be done with system() of stdlib of mingw?
b. How to achieve it?
Note :
I have read about createProcess and its subsequent usage in the net - But my idea is to continue with existing code (use system() call itself) and find an alternative to WEIXTSTATUS.
Thanks for your help/suggestion in advance.
Look here for Win32 documentation on system: http://msdn.microsoft.com/en-us/library/277bwbdz%28v=VS.100%29.aspx
Note that the system call is subject to the command interpreter on the system, and cmd.exe (Windows command interpreter) works differently than Unix Bash.
Hey there, I'm building a remote shell server that interfaces between a text-only client and a virtual shell.
It works perfectly when using regular shell commands, but the first thing that people try after that is vim, which promptly drives my server crazy and can't even be closed remotely.
Is there any way to detect ncurses based programs and prevent them from running in my special shell?
(the server is ruby, but any system command will do)
You can declare the capabilities your shell has, by setting the TERM environment variable to the correct value. For instance, if your shell has the same capabilities as the vt100 terminal, export TERM to the correct value, and programs like vim will respect that.
To run vim in vt100-mode, try:
TERM=vt100 vim
You could also try:
export TERM=dumb
The trick is to find a terminal that corresponds to the capabilities of what you are creating. There is a lot to choose from. On my system (Arch Linux) this gives me a long list of choices:
find /usr/share/terminfo
You might be able to find a terminal specification that corresponds to what your program can handle.
Alternatively, you may want to consider implementing terminal emulation for ansi or vt100:
http://en.wikipedia.org/wiki/ANSI_escape_code
http://www.termsys.demon.co.uk/vtansi.htm
Best of luck!