Linux: Shells
-
When UNIX was first created, the only way to run something on it was to compile a C program that could talk directly to the OS via system calls. This lasted for, I imagine, about one day before someone decided that something more robust was in order. The original UNIX shell, called the Thompson Shell (sh) shipped in 1971 and introduced many of the basic concepts that we think of as being part of UNIX to this day. In 1979, Stephen Bourne also at Bell Labs like Thompson, wrote a new shell to replace the eight year old one. This shell is known as the Bourne Shell (sh) and is effectively the parent of nearly all major UNIX shells to this day. (Remember, nothing requires UNIX systems to ship with or implement a Bourne-style shell, but no enterprise non-Windows system does not use one and even Windows uses one optionally.)
Different UNIX systems have chosen different shells as their defaults. Even within the Linux ranks there are some variations in the defaults. But by and large, and for the Red Hat family, the default on Linux is the Bourne Again SHell, commonly known as BASH. BASH is not new, by any stretch, but it is actively developed and supported and has a wide variety of moderately modern features.
When using any UNIX system, it is very trivial to switch to a shell that is not the default. In fact, this is easy to do on Windows, too. Today the Windows world offers three standard shells out of the box: Command Shell (cmd.exe), PowerShell and the Windows graphical desktop (a graphical shell.) People tend to call the last one a desktop, but desktops are a shell as well, but rarely what people mean when they use the term. So having a variety can be important as someone may seek different functionality, or more often, may seek commonality between multiple systems. For example if you have mostly Linux Admins but a few AIX systems in the environment, it might be common to use BASH on AIX. If the opposite were to be true, it might be common to use ksh on Linux.
Even old systems like the Amiga 1000 in 1987 shipped with two three shells by default: Amiga CLI (closer to DOS), Amiga graphical desktop and Amiga Shell (a Bourne Shell.)
The common UNIX Shells:
- ash: The Almquist Shell, a Bourne style replacement for the original with BSD licensing. A POSIX enhanced version of ash is the standard shell on FreeBSD and NetBSD.
- bash: The Bourne Again Shell, a GNU (GPL) licensed replacement for the Bourne shell. The standard shell for most of the Linux family.
- csh: The C Shell, written by Bill Joy (Sun founder and father of NFS) for BSD Unix. Today the implementation of csh that you will find in most UNIX system is the upgraded, TENEX CSH (tsch). On Windows and OS/2 is it the Hamilton CSH.
- dash: Debian Almquist Shell. An ash replacement common on Debian and Ubuntu systems.
- ksh: The Korn Shell. That it rhymes with Bourne is a bizarre coincidence in the UNIX world. Also written at Bell Labs as a replacement for the Bourne shell, the third of the official, original UNIX shells from Bell themselves. ksh is still used on IBM's AIX and is the basis for the POSIX standard on shells.
- zsh: The Z Shell. A modern BASH replacement incorporating the best of BASH, ksh and tcsh along with many enhancements of its own. Not common in any environment but widely available and the most common "upgrade shell" for those looking to use more modern features.
Also worth noting is the new fish shell that brings much more modern features to the command line. The only major (if it can be considered major) shell written after 1990 (when zsh was written), it is from 2005 and unlike all of the other shells here, is not a descendent of the Bourne or Joy's C shells.
-
It should be noted that for the casual user, nearly all shells will be identical. The command prompt might vary, but most everything will work as expected. It is only when using the shell languages to program or using more advanced features like command completion that we start to experience differences in how the different shells handle things.
Also of note, any REPL is actually a shell. So, while not well suited to general use, it is entirely possible to use a Perl, Python, Ruby or other interactive programming REPL as a makeshift shell.
-
-
-
Bash is coming to win 10
http://techcrunch.com/2016/03/30/be-very-afraid-hell-has-frozen-over-bash-is-coming-to-windows-10/ -
@Mogrith said in Linux: Shells:
Bash is coming to win 10
http://techcrunch.com/2016/03/30/be-very-afraid-hell-has-frozen-over-bash-is-coming-to-windows-10/We have a couple of threads on that. It sounds amazing at first, but it turns out to be totally useless and a marketing trick. It's not BASH for Windows, that already exists via Cygwin. It's BASH for a weird, useless container on top of Windows 10... for all intents and purposes in a VM. So the BASH can be used to work in its own little useless environment, but can't interact with Windows 10. So has no actual purpose, sadly. We were all very excited about it until the news came out that it was totally useless by being isolated.
If you want Ubuntu on Windows (the thing, not the product with the intentionally misleading name) you still have to fire up Hyper-V or VirtualBox and install a full VM sadly.
-
@scottalanmiller said in Linux: Shells:
@Mogrith said in Linux: Shells:
Bash is coming to win 10
http://techcrunch.com/2016/03/30/be-very-afraid-hell-has-frozen-over-bash-is-coming-to-windows-10/We have a couple of threads on that. It sounds amazing at first, but it turns out to be totally useless and a marketing trick. It's not BASH for Windows, that already exists via Cygwin. It's BASH for a weird, useless container on top of Windows 10... for all intents and purposes in a VM. So the BASH can be used to work in its own little useless environment, but can't interact with Windows 10. So has no actual purpose, sadly. We were all very excited about it until the news came out that it was totally useless by being isolated.
If you want Ubuntu on Windows (the thing, not the product with the intentionally misleading name) you still have to fire up Hyper-V or VirtualBox and install a full VM sadly.
The weird thing to me is why anyone would want a bash shell on Windows for windows. I see this shell more for you to make connections to Linux boxes to control them, less about controlling the Windows 10 machine itself. But what do I know?
-
@Dashrender said in Linux: Shells:
The weird thing to me is why anyone would want a bash shell on Windows for windows. I see this shell more for you to make connections to Linux boxes to control them, less about controlling the Windows 10 machine itself. But what do I know?
BASH has nothing to do with Linux or UNIX. It's a shell, like a programming language. Why would you want BASH on Linux but not on Windows? If you want it on Linux, why would you not want it on Windows? And BASH isn't about connections, that's SSH, BASH is the programmatic interface that you use.
People choose BASH on Linux, a platform where many choices exist, because it is common, powerful, easy and familiar. Some people use ZSH or FISH, but BASH is the big winner amongst many possibilities. We want it on Windows for the same reason... why would we want something else on Windows when we chose the "best option" on Linux?
-
@Dashrender said in Linux: Shells:
I see this shell more for you to make connections to Linux boxes to control them..
Not sure what you mean, how would BASH do that and why? You'd want "whatever shell you are using on Windows" for that, ideally.
-
And this is the failing to the uninitiated. I don't really understand what the shell does. I don't understand what makes it work differently than another one.
Just telling me that it's like two different programming languages doesn't help when I'm not a programmers. I've done a tiny, and I mean microscopic amount of programming, so I know that there are key word differences, grammar differences, etc - but I still don't understand what makes one language better than another for a specific task, and the same applies here for shells.
You even say in your explanation that one shell to another (on LInux) the normal user won't be able to tell the difference - it's not until you dig deep with programming, but I don't understand why that is?
-
@Dashrender said in Linux: Shells:
And this is the failing to the uninitiated. I don't really understand what the shell does. I don't understand what makes it work differently than another one.
Think: "Programming language with handy access to system calls."
The common shell that you know is the Windows graphical shell. You just call it the Windows desktop. That's a shell. Shells are the things that provide the user interface to the operating system.
-
@Dashrender said in Linux: Shells:
You even say in your explanation that one shell to another (on LInux) the normal user won't be able to tell the difference - it's not until you dig deep with programming, but I don't understand why that is?
For example, BASH lacks complex data types that some other shells have. But if you are not doing programming that would use them, you'd never notice. But BASH and ZSH share a syntax (they both use BASH syntax.) So anything you do in BASH works on ZSH, but somethings that you do on ZSH won't work on BASH.
ZSH also has more advanced completion. Like you can tab complete host names, for example, which BASH can't do.
-
@Dashrender said in Linux: Shells:
Just telling me that it's like two different programming languages doesn't help when I'm not a programmers. I've done a tiny, and I mean microscopic amount of programming, so I know that there are key word differences, grammar differences, etc - but I still don't understand what makes one language better than another for a specific task, and the same applies here for shells.
For example, let's think about graphical shells. Let's say that you want to work with both Windows and CentOS and you want to do so graphically... would you want each to have a unique graphical environment with a different look, feel, different mouse actions and gestures, menus in different places, etc? Or would you want to choose the best of the two and have both do the same thing so that you can move back and forth without having to change anything that you do?
-
the programming part is where I'm completely lost.
-
@Dashrender said in Linux: Shells:
the programming part is where I'm completely lost.
Then ignore that part. Think of it as "interface."
-
@Dashrender said in Linux: Shells:
And this is the failing to the uninitiated. I don't really understand what the shell does. I don't understand what makes it work differently than another one.
English and French are different. They can accomplish the same things, but they get there in different ways. Programming languages are a lot like that. Some things are easier to do in English, some things are easier to do in French. But nothing is easier than getting to speak in your own language all of the time.
-
@StrongBad Good analogy.
@Dashrender: Different shells provide you with different programming (or scripting) capabilities. For example, zsh and (k)sh differ in word splitting. Here's a good read about that: http://zsh.sourceforge.net/FAQ/zshfaq03.html#31. And here's how zsh differs from other shells at a more global scope: http://zsh.sourceforge.net/FAQ/zshfaq02.html
-
@thwr Thanks
