Best Shell for UNIX systems

knightjp

knightjp

What would be the best shell for POSIX system (Tcsh, Bash or Zsh)..?

Makes me wonder why Apple moved away from Bash to Zsh and why not Tcsh since they quite a bit of code from the BSDs?
 
I like zsh. But probably not «the best».
I think you can experiment few of them and find a good one for you.
But please, don't use «source» in your script ;-)
 
Yeah shells, can never make up my mind on them. For now I'm just using the default and let that decide for me. I just learn whatever shell the system defaults to and if I can't do something there I'll look into something else, which I have not yet had to do.
 
sh for lean scripts.
bash for colourful directory listings and command prompts, and a bit more useful comfortable usage.

Apple moved away...
Click to expand...
Do you imagine all those people that love apples even know what a shell is?
 
I still prefer the sh shell for my regular account. It performs well and the mising history between sessions trains my brain to learn commands by hard heart.
 
I'm a csh person, I use it on all my FreeBSD systems, even on "regular" accounts. Makes it easier to deal with both normal users and root, only one shell to worry about.
 
I use shells/zsh for interactive use with very few additions/modifications and POSIX /bin/sh for scripts.
But "best" is subjective 😊

knightjp said:
Makes me wonder why Apple moved away from Bash to Zsh and why not Tcsh since they quite a bit of code from the BSDs?
Click to expand...

I suspect the removal of shells/bash is due to the fact they are on the latest version licensed under the GPLv2, and is 10+ years old.

Why shells/zsh? It's MIT licensed, and it'll be mostly compatible to shells/bash, and won't break most of the almost 20 years of articles built up over the Mac OS X/macOS lifetime. Switching to something like tcsh would break a lot of little one-liners, and would be more unfamiliar to anyone who occasionally dabbles on the command line.
 
I use fish 'cause there's almost zero setup. The "setup" consists of me issuing the fish command, waiting 10 seconds, exiting, copying my "functions" directory to the new OS, and entering fish again. Done. :cool:
 
I've worked with different Unix / Unix-like systems and the question of the "best" shell (or editor, or whatever) has always been answered by other people. ;) And unfortunately, when you log in to an enterprise server as a developer, you don't have the root password to change what you don't like. ;)

This is why I stick to sh (available everywhere) both at work and at home so as to feel comfortable in any context. Same with vi, also available on all systems, which is not the case with vim or neovim. I also apply the same principle with my keyboard: I've put stickers on the keys so I have the same layout at work and at home.

I've noticed I work faster, safer and more comfortably using well known tools rather than the "best" tools.
 
For an interactive shell, pick your poison. A long time ago I knew somebody who used /bin/ed as his primary user interface, using ed's "!command" to execute shell commands (a mechanism to manage the history of Bourne shell commands on V7 Unix).

I generally want the shell scripts I write to work universally. So portability is a really big issue.

For scripts used in the "early boot" context you may be constrained to use /bin/sh. My experience is that /bin/sh will struggle with full POSIX compliance on just about any Unix/Linux variant you name. For me, this certainly includes:
  • FreeBSD /bin/sh;
  • Debian /bin/sh (dash);
  • RedHat /bin/sh (bash, but behaves differently due to its invocation name);
The common denominator with these is not POSIX. It's the "Bourne shell". e.g. older versions of dash can't catch stdout with "$(command)".

So for "early boot" scripts, I use Bourne shell. However, I reckon that few people really understand exactly what a Bourne shell is today.

Outside the "early boot" process, I still want portability. My own rule is that as soon as I think I need non-Bourne syntax, I switch to perl (substitute python if you're younger than me).

That will generally happen because I really need an array of some kind, or serious use of regex (without fork and exec).

However, it's OK to use the specific local shell if portability is maintained, e.g. iptables or LVM scripting must be on Linux, so bash is OK.

If speed matters, ksh is pretty lean and mean, bash is an absolute dog, and perl rocks.
 
gpw928 said:
I use Bourne shell. However, I reckon that few people really understand exactly what a Bourne shell is today.
Click to expand...
Oh really?

Assuming it is the members of this forum that you are addressing, please explain, what you know that you expect us not to understand.

Thank you.
 
Geezer said:
Assuming it is the members of this forum that you are addressing, please explain, what you know that you expect us not to understand
Click to expand...
I was talking about portability, and the context specifically included citation of two different versions of Linux (as well as FreeBSD).

So that's really not a fair assumption.

My subjective observation is that people who use Unix and LInux are frequently only (semi-)competent in the command line shell they use. Almost universally, that is not /bin/sh.

One would expect professional administrators and forum members to be somewhat more erudite, but still to display a spread of "shell skills", under a bell curve.

In any event, it's very difficult to find an authentic Bourne shell today on which to test. I expect that Solaris might have one (it used to). I don't know of any others, off the top of my head.

Here is the test I used to use on Solaris:
Code: 
[ritz.1095] $ cat /usr/local/bin/bourne
#!/bin/sh
# Only a genuine Stephen R. Bourne shell interprets "^" as a pipe, and returns 0
false ^ true
 
We have to distinguish the shell in which you program (write shell scripts which get stored and used for long periods), and the shell in which you work interactively.

For the former, you may want something with portability, and a relatively limited set of functions, so the scripts remain readable and don't rely on crazy and difficult-to-understand tricks. I like to use (k)sh for it, without relying on special things that are only available in particular implementations like bash.

For interactive, my personal preference (everyone is different) is good keyboard related commands: command line recall with search, emacs editing keys, history file, and so on. I happen to use bash, because it has all that and is easily available on all OSes. Other people's preferences may vary.
 
/bin/sh for root (leave it) and scripts, mksh (ports) for interactive use.
 
I prefer using shells/pdksh for my regular account while I keep /bin/csh as the default root shell. I've become to really appreciate having to re-think the stuff I want to do as root this way.

Of course my setup is a bit specific, my shell even has the vi mode turned on by default which does miracles for me. Not only can I easily use regexps to find commands which I used in the past, if someone else finds themselves behind my console they usually end up stuck and locking themselves out (don't try the cursor keys in vi mode ;)).
 
A manual always contains the rule of the thumb. Having zsh for root is just easy on a desktop.
I would not do it on a server. security etc ...
mksh , i need to have a look at that one.
One must differentiate beween script shell and interactive shell.
For a script shell I would go for sh.
 
Last edited:
You must log in or register to reply here.
Back
Top