What Linux shell should I use?

Question

I've used bash, csh, and tcsh. But I asked this question, and Jonathan informed me that csh isn't to be trusted. So what Linux shell is good for development. and why?

Answer 1

I usually stick to bash, because it's more friendly than straight-up sh, and it's the default on every distro I've used semi-regularly (SuSE, RHEL, Ubuntu, Slackware).

If you're planning to write portable shell scripts, however, make sure they all run in real sh.

Answer 2

The most common shell, by far, on Linux is bash. Unless you have a good reason to use an alternative, I'd suggest that sticking with bash, or the most commonly used shell by your project team (or that the bulk of the shell scripts you have to work with) uses.

The only other very common contender is dash, which is becoming more widely used by the Ubuntu project.

This really is personal preference, well, except for csh.

Answer 3

Bash. It's standard.

Answer 4

Just don't use Korn Shell (ksh).

Unless you have perfect typing and never need to use the backspace key.

Answer 5

I like ksh actually. It's a bit more consistent than bash because it does not try to support any csh constructs. tcsh, in my experience, is least compatible with other shells, and I avoid it. I try to write scripts to sh, but ksh does have some nice features like exporting and setting a variable on one line. I try to preserve compatibility with bash as well, since it is full-featured and common. To write portable shell scripts, which is more important than selecting the "best" shell, you might consult this book.

Portable Shell Programming: An Extensive Collection of Bourne Shell Examples (HP Professional Series) by Bruce Blinn (Paperback - Oct 29, 1995) amazon.com

Answer 6

I prefer zsh.

The tab-completion alone is worth it:

• It expands wildcards if you want(handy when you want to delete all but one file in a directory)
• Will give you a list of switches after specifying a program
• Gives tab completion options below the line you're working on, which is pretty handy.

http://zsh.sourceforge.net/

Answer 7

I use pdksh all the time without having anything close to perfect typing (perhaps you need to fix your termcap?).

ksh is the standard, csh is a standard and bash is 'standard', but on linux only. Better to target ksh.

Answer 8

Since I believe I'm the person who suggested that you should use something other than C Shell, perhaps I should should qualify my remarks slightly, and then support those who said 'bash on Linux, Korn shell on other platforms (unless bash is installed there too)'.

Rather like editors (do you prefer vim or emacs), choice of shell is partly a question of familiarity and partly a question of preference. There are many who like C shell, though I do believe that it is less easily programmable than Bourne shell and derivatives. What I have in my .cshrc is, indeed, equivalent to exec /bin/ksh (it isn't identically that because I want to execute a login shell - one that reads the profile and so on), but I wouldn't condemn anyone for using C shell or a derivative if it is an informed decision.

If you decide that you want to use something other than C shell, then you are basically in the Bourne shell camp, for which the POSIX standard more or less specifies the expected behaviour and then the different shells -- that is, the Bourne, Korn or Born Again shells -- add (or, in the case of the classic Bourne shell, subtract) a few features. If your code might ever need to move off Linux to HP-UX, Solaris or AIX (the surviving trio of the classic, AT&T-derived Unix variants), then you should consider ensuring you write your shell scripts in classic Bourne shell, though Korn shell is also pretty safe. Note, though, that on Linux you can write #!/bin/sh and get Bash, on the other platforms, you will get Bourne shell.

I switch between Korn shell and Bash without major problems - and seldom with minor problems. I tend to stay clear of those corners of either language that are not well defined - which tends to mean 'defined in both'. Another problem for those using Linux is that the GNU tools have more options than the classic Unix versions, and you can lose portability not because of the shell programming constructs that you use but because of the command options you use. Experience and ready access to the manual pages of other systems helps enormously.

Answer 9

For interactivity, use Zsh. For a while I was the maintainer of the FreeBSD port of the Bash tab-completion scripts, but abandoned it as soon as I tried Zsh for the first time. It can do everything Bash can do but more easily and more elegantly. It also has the nice property of having extremely Bash-like keystrokes, so if you're on a system without Zsh, you'll be able to make do (even if it wouldn't "feel" as nice).

For scripting, use Bourne Shell (sh). It's the POSIX standard scripting language and your scripts are pretty much guaranteed to work everywhere. Bash and Zsh and other shells have nice extensions that you'll miss but those tie you to a specific setup. Ignore that advice for personal-use-only scripts that you're certain you'll never run elsewhere, but remember that it's a real tradeoff that you need to consider.

But in summary, Zsh. I don't know of anyone who's tried it who didn't immediately and permanently switch. It really is that good.

Answer 10

The problem with csh is that it's crap for scripting, as explained here. There's no real reason why you shouldn't use it as an interactive shell, but most people find it confusing having to learn two different shells and not being able to try out bits of their scripts on the command line, so it's easiest to use the same for everything.

The obvious candidates for an interactive shell are bash, dash, zsh and {pd,}ksh. All of these implement the posix shell standard, with some minor extensions. Pick whichever you like for interactive use, I'd tend to go with bash just because it's the standard on linux but they all have their merits and zsh in particular seems popular.

If you're writing a script that you intend to be portable, use #!/bin/sh, and make sure you use standard posix shell syntax. If it works on both bash and ksh it's probably standard. There are some old versions of unix which have a non-standard /bin/sh but I wouldn't bother with that unless you know you have to. More of a problem for portability are all the command line tools you call from your script.

Answer 11

I haven't tried it yet, but fish looks promising.

Answer 12

I'm not big Ruby user but http://rush.heroku.com/ looks interesting

Answer 13

Fish (Friendly Interactive Shell) is a nice alternative to most of the other shells. It has a consistent syntax, nice tab completion and syntax highlighting, is easy to pickup and use (especially if you don't have habits from other shells), and has excellent runtime help.

Downside is that it's erratically developed, has a small (but helpful) user base, and is very different than other shells. Backwards compatibility with shell idioms was not a priority.

In many cases this is good... a lot of the standard shells have really stupid ways of doing things, just because it's always been done that way. "do/done", "case/esac", "if/fi"? This is insanity that fish does away with.

It's worth a look.

Answer 14

It's probably best to stick with bash simply because it's the most widely used as a shell and any tutorials or help you may receive from someone will most likely use bash. However, I have started using zsh for all of my scripts and I have found it to be far superior to bash in terms of scripting.

Answer 15

For writing actual scripts, I prefer ksh, which has several extensions useful for programming and fixes one of my pet annoyances.

bash is my preference for interactive sessions, but that is more a matter of personal preference than anything else. Just be sure it is a Bourne-type shell.

Answer 16

I came also from csh, tcsh to bash. It's different but after some time, at least as nice as the c-shells.

For Scripting I would recommand ksh, because it's available on most Unixes (Solaris, HP-UX , OSF/1 (The best UNIX ever ;) - for it's time)) and it has good features. With Korn you can programm most of the scripts. Sporadicaly you would like to get more then a number, as return value from a function, or you have some data that you can not put in a simple array, or you need something that has better capabilities in case of regegs, or what ever, then I would propose perl.

Answer 17

For scripting, try using dash for a while to get a good feel for what is portable. If you ever use bash to write a shell script, please explicitly declare bash in the scripts shebang.

For your personal console use, experiment with what is out there. Find something that you're comfortable with. Be eccentric and annoy all your sysadmin friends by picking up a shell that has to be compiled from source for every machine you care to use it on.