I have read in Codecademy that
To access the command line, we use a terminal emulator, often just
called the terminal.
This gave me the impression that PowerShell and Command Prompt are terminal emulators but when I checked the list of terminal emulators for windows I found the following list in Wikipedia. I would really appreciate it if anyone can help me understand what terminal emulators are, what PowerShell and Command Prompt are, How these things are different. Thank you!
Terminal emulators are applications that emulate the behavior of character-oriented hardware terminals from the early days of computing. For all practical purposes, the Windows Console is an instance of a terminal emulator, as is its modern successor, Windows Terminal.
Typically, the applications that run inside these emulators are interactive shells[1] such as PowerShell and cmd.exe, which act as command-line interpreters, which enable running other applications as well as commands built into those shells and scripts written for those shells.
[1] On Windows, somewhat confusingly, the term shell is also used for the graphical (GUI) shell that provides the Windows desktop and File Explorer. Overall, however, the term shell usually refers to terminal-, character-based shells, such as the POSIX-like shells in the Unix world (a prominent example of which is Bash), and to PowerShell on Windows, as its name implies; while the term conceptually also applies to cmd.exe, historically it hasn't been used much in that context.
Related
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.
In the past, I have used MATLAB sparingly from Linux machines at work, and I far and away preferred using the '-nodesktop' option. On all Unix-like machines I've worked on this option allows me to control STDIN and STOUT with relative ease, but on Windows(using Cygwin) this option spawns a new window and control is returned to the calling shell!
Basically, I would like to know if there is any way that I can force MATLAB to behave as it would on a Unix-like machine?
Thanks!
Short answer: You can not.
A longer answer can be found on their website.
-nodesktop behaves differently depending if you are on Windows vs
Linux or Mac. On Windows we provide a boring Command-Window only
interface that lacks the “bells and whistles” of the regular Command
Window or the full Desktop.
So you can use -nodesktop, but it pops up that annoying command line only window.
I have been reading how to use a shell inside EMACS, along the way I found the concept of Terminal, which is an abstraction for the old physical devices which interacted with the shell.
But, nowadays, I really can't understand which are the advantages regarding its use, so, can you please point me out a couple of situations or examples where one should use it instead of the shell in Emacs?
Running a term buffer is much closer to an actual terminal. Here are a few differences:
Shell mode provides very limited terminal emulation. Programs that take advantage of the terminal's full-screen capabilities (e.g. less, mtr, mutt, top) won't work properly. Terminal mode will generally handle these without any problem.
In shell mode, emacs provides tab completion. In terminal mode, the shell or command-line program provide it themselves.
Shell mode buffers the input and sends it to the process on newline. Terminal mode sends the characters to the running process immediately.
Shell mode works like a regular buffer with the usual emacs key bindings. Terminal mode doesn't intercept most control characters unless you explicitly put it into line mode.
The shell is like another emacs buffer, so the same keys work in it which work in other buffers. It is not true for the terminal.
You can launch the console programs that clear the screen like mc in terminal.
Physical terminals are long obsolete, but the terminal emulators which replaced them are pretty important, and I would presume that most shells outside of Emacs are run within one, so it's not such a mysterious concept to use one within Emacs too.
It's only tangential to your question, but The TTY demystified is an excellent article which you might find enlightening.
I don't know if this is a dumb question or not but again as my professor says if you have doubts then clear them . What is the difference between Linux text mode and windows command prompt (cmd). I know both windows and Linux are different Operating Systems but when you look at the commands, some of the commands are common For Example cd command.
Although superficially similar in some ways, the two command line interfaces have different lineages:
The Windows command prompt is based heavily on that of MS-DOS / PC-DOS, which in turn was based on the CP/M Console Command Processor. The CP/M CCP interface was itself based on an earlier operating system called RSTS.
The Linux shells trace their roots back to the original UNIX Thompson shell; the Thompson shell borrowed from the Multics shell (where the term "shell" originated).
Traces of these are still evident today - the DIR command in the Windows command prompt can be traced all the way back to the DIR command in RSTS, and similarly the ls command in GNU coreutils can be traced back to the Multics "list segments" command.
They're both based on the same idea and are called Command-Line Interfaces (see wikipedia). They operate off the same principals, just using different keywords to perform similar commands. It should be noted however, that the commands although similarly named, may not perform the exact same function. They are just abstractions of lower level functions of the operating system. Just like people can explain similar ideas using different words and phrases, the same applies in this situation. For reference here's a list of Bash commands: http://ss64.com/bash/ and the same website has windows commands.
The difference is the operating system. The command prompt (cmd) and a terminal emulator (linux bash shell or similar) are text interfaces to the operating system. They allow you to manipulate the file system and run programs without the graphical interface.
You should read about Linux shells. The Bash shell for instance, is among the most used Linux shells... ever!
http://doc.dev.md/lsst/ch01sec07.html
http://www.tuxfiles.org/linuxhelp/shell.html
And if you're looking for a list of commands: http://www.physics.ubc.ca/mbelab/computer/linux-intro/html/
It is not that commands are in common (well yes, maybe some), it is that they have the same name and do almost the same things, as for cd as you said.
The shells are an abstraction of the underlying operative system, Linux and Windows have a different kernel, hence the difference.
You might want to start here with your reading.
Looking for a better Windows XP command-line interface. The Visual Studio Command Prompt isn't near as nice as the Linux/OSX terminals.
Thoughts?
edit:
Answers: Console on Sourceforge, and the Windows Powershell. Thanks, I'll go dig them up and evaluate them.
The Cygwin package is too much overhead for what I want.
edit2:
Looks like the Windows Powershell for now. Its copy&paste functionality isn't great, but MS supports it.
Take a look at Console2 http://sourceforge.net/projects/console/
It's features:
"multiple tabs, text editor-like text selection, different background types, alpha and color-key transparency, configurable font, different window styles"
As has your question been tagged, have you tried Windows PowerShell? It's paradigm is based on unix's pipes but instead of outputting text the processes output .Net objects.
cygwin? www.cygwin.com. Or mingwin?
Cygwin
This is an answer extending line.
I'm not clear on what you mean by Linux/OSX command prompts being "nice". If you just mean that they provide more utilities, I usually install Windows Services for Unix to add common programs like grep and vi.
I see you put "powershell" as one of your tags. Maybe you could help direct our answers by explaining what you don't like about PowerShell as a replacement for cmd.exe?
I use Take Command from JP Software
Cygwin is a good alternative. You can run Bash or other shells on Windows. You get most of your classic Linux/UNIX commands, shell scripting, etc. You even get the GNU compilers and can avoid Visual Studio if you wish. From Cygwin, you can access your regular Windows programs, drives, etc so there's rarely a reason to go back to cmd.exe.
If you are just looking to automate tasks via shell scripts (not interactive shell), then you should look at Windows Scripting Host. WSH is a feature-rich scripting environment for Windows that comes pre-installed on all modern versions of Windows.
I've been combining putty, cygwin, screen, and zsh(not bash) lately. I like a lot of the features of zsh, like autocd which and auto-pushd, which put the directories you change into onto the directory stack without having to type pushd. I also like that fact that multiple shells share history, and don't overwrite each other. Screen lets me run multiple zsh shells in one putty window. You can get zsh and screen from the cygwin site. I run: putty -cygterm screen
You'll also need the patched version of putty that has the -cygterm support.
GitBash by git is also a good option. It can be configured to be used in unix like environment.
It can be downloaded from here http://msysgit.github.io/