# Best Shell for UNIX systems



## knightjp (Oct 12, 2019)

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?


----------



## Hakaba (Oct 12, 2019)

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 ;-)


----------



## yuripv (Oct 12, 2019)

knightjp said:


> best shell for POSIX system


`/bin/sh`

For interactive shell, use the one that you know better.


----------



## CraigHB (Oct 12, 2019)

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.


----------



## Hakaba (Oct 12, 2019)

At the begining, OS X use tcsh I think.
But as I use zsh, Apple probably decide to follow my decision...


----------



## aht0 (Oct 12, 2019)

Tcsh. I've worked out my own .cshrc for colored Linux bash-like shell tho, which I use on BSD (FreeBSD & DragonFly) and Linux..


----------



## D-FENS (Oct 12, 2019)

knightjp said:


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


zsh. But you need styling, like any other shell.



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?


Because it is cool, it has nice compatibility features and it's also very powerful. Not very easy to learn though.


----------



## trev (Oct 13, 2019)

`/bin/sh` for scripts and `/bin/tcsh` for interactive use.


----------



## Geezer (Oct 13, 2019)

`sh` for lean scripts.
`bash`for colourful directory listings and command prompts, and a bit more useful comfortable usage.



> Apple moved away...


 Do you imagine all those people that love apples even know what a shell is?


----------



## vermaden (Oct 13, 2019)

For scripting - POSIX /bin/sh.

For interactive use I prefer ZSH but anything modern would do - like FISH for example.


----------



## D-FENS (Oct 13, 2019)

Geezer said:


> Do you imagine all those people that love apples even know what a shell is?


I suspect that some don't know what a file is


----------



## meine (Oct 13, 2019)

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.


----------



## neel (Oct 13, 2019)

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.


----------



## Alain De Vos (Oct 13, 2019)

my shell for root is zsh


----------



## forquare (Oct 13, 2019)

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?



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.


----------



## LakeCowabunga (Oct 14, 2019)

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.


----------



## 20-100-2fe (Oct 14, 2019)

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.


----------



## gpw928 (Oct 14, 2019)

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.


----------



## Geezer (Oct 14, 2019)

gpw928 said:


> I use Bourne shell.  However, I reckon that few people really understand exactly what a Bourne shell is today.


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.


----------



## gpw928 (Oct 14, 2019)

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


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:
	
	



```
[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
```


----------



## ralphbsz (Oct 14, 2019)

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.


----------



## DutchDaemon (Oct 14, 2019)

/bin/sh for root (leave it) and scripts, mksh (ports) for interactive use.


----------



## ShelLuser (Oct 14, 2019)

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 ).


----------



## D-FENS (Oct 14, 2019)

Alain De Vos said:


> my shell for root is zsh


They say you should not change your root shell!


----------



## Alain De Vos (Oct 14, 2019)

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.


----------



## D-FENS (Oct 14, 2019)

Alain De Vos said:


> A manual always contains the rule of the thumb. Having zsh for root is just easy ,it's not your PC takes fire.
> In the event zsh should break , you recover with a USB stick.


Their point is valid. I have locked out my root user for real in a system where I had an error in my root's zsh profile. If you have a bad .zshrc, game over. You need to restore from the installation CD.
If you're fine with taking your system offline and restoring - sure, go for it. Maybe I do it myself too.


----------



## gpw928 (Oct 15, 2019)

roccobaroccoSC said:


> They say you should not change your root shell!


I really hate struggling with csh in single user mode.  At a time when I need to be sharp, I find myself stumbling in the dark, cursing csh, and no man pages available.
So, I make sure I always have the shell that works for me:
	
	



```
[ritz.1131] $ grep ^root /etc/passwd
root:*:0:0:Charlie &:/root:/bin/ksh
[ritz.1132] $ grep ^/bin/ksh /etc/shells
/bin/ksh
[ritz.1133] $ file /bin/ksh
/bin/ksh: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), statically linked, for FreeBSD 11.3, FreeBSD-style, stripped
```
This is not at variance with the reasons given for what they say (shell may not be available if /usr not mounted), because a statically linked binary in the root has no dependencies.
The pdksh port has an option for static linking.  The "make install" goes into the /usr/local prefix.  I copy the binary manually to the root, and manually modify /etc/shells.
I accept that I have to maintain it manually.  I keep abreast of both pdksh shell and libc patches (pdksh uses only one system library, libc, so it's not hard to keep watch).
All my FreeBSD systems have been like that since 1997, to no ill-effect.


----------



## Geezer (Oct 15, 2019)

DutchDaemon said:


> /bin/sh for root (leave it) and scripts, mksh (ports) for interactive use.



So what is mksh? 
On the website https://www.mirbsd.org/mksh.htm, it says "The MirBSD Korn Shell".
Well that does not really help.
In fact, going through the entire website for mksh, and I am still lost.

All the other shells that are mentioned on this thread, either I know them or I can find out what they do. Some I like and some I don't. I do have the choice.

But I can't be [expletive] X!#* [/expletive] with anything exclusive.

Thank you.


----------



## gpw928 (Oct 15, 2019)

Geezer said:


> So what is mksh?



It's a fork of pdksh, so the genealogy is V7 Bourne clone -> BRL shell -> pdksh -> mksh.

There's some venerable names associated with that lineage.

It's widely available, but today, it's arguably most famous for being the default shell on Android.


----------



## xtaz (Oct 15, 2019)

roccobaroccoSC said:


> Their point is valid. I have locked out my root user for real in a system where I had an error in my root's zsh profile. If you have a bad .zshrc, game over. You need to restore from the installation CD.
> If you're fine with taking your system offline and restoring - sure, go for it. Maybe I do it myself too.



Not quite true. All you have to do is boot into single user mode from the boot menu and then select an alternative shell at the prompt. If the system is absolutely hosed then /rescue/sh is usually a good choice. This gives you enough to be able to fix what you broke.

The main reason for never changing roots shell used to be that /usr/local/bin was usually mounted separately to the / filesystem and if for any reason it failed to mount it would leave you broken. These days there is a good chance those two are on the same filesystem anyway.

Or alternatively the shell binary may be dynamically linked against other dependencies that may break. Like libncurses or something. This can be solved by compiling the shell as a static binary which ports like shells/bash let you do. There's even a package for it called shells/bash-static.

So basically, it's not the end of the world if you do this, just that you need to know the consequences, and how to deal with any issues that may happen.


----------



## Alain De Vos (Oct 15, 2019)

There is zsh static also. But sometimes zsh can complain , like when there is no .history file.
Note : pdksh has also emacs edit mode.


----------



## D-FENS (Oct 17, 2019)

gpw928 said:


> I really hate struggling with csh in single user mode.  At a time when I need to be sharp, I find myself stumbling in the dark, cursing csh, and no man pages available.
> So, I make sure I always have the shell that works for me:
> 
> 
> ...


You could also always manually type "zsh" when you login as root. It works.


----------



## gpw928 (Oct 18, 2019)

roccobaroccoSC said:


> You could also always manually type "zsh" when you login as root. It works.


It's certainly true that zsh is, to me, vastly more preferable than csh.
However, zsh has a dependency on /usr/lib/libdl.so.1, and if /usr is mounted (or in the root), then I could just type "ksh" (or ksh93) for a dynamically linked ksh.
My approach "fails safe" under all circumstances.


----------



## Alain De Vos (Oct 18, 2019)

When it's statically compiled one does not care,everything included. Unless, your .zshrc has a problem.
Milliseconds can be important on embedded systems but not on a desktop.


----------



## D-FENS (Oct 18, 2019)

gpw928 said:


> It's certainly true that zsh is, to me, vastly more preferable than csh.
> However, zsh has a dependency on /usr/lib/libdl.so.1, and if /usr is mounted (or in the root), then I could just type "ksh" (or ksh93) for a dynamically linked ksh.
> My approach "fails safe" under all circumstances.


ksh93 has a cool feature. You can change argv[0] which has been  quite handy in some situations I have encountered.


----------



## Alain De Vos (Oct 18, 2019)

a good shell has a good interactive documentation. So I press this button it will do this.


----------

