What is your favorite shell.

Alain De Vos

Alain De Vos

A shell can be used interactively & non-interactively. But what is your favorite & why ?
I recently learned mksh, once you know vi-keys it's quiet ok.
 
After moving on from tcsh which has the big disadvantage of treating exclamation marks as commands even when configured otherwise (if anyone could guide me how to have “!!” in strings, like archive passwords, not mess with my history, please do!), my interactive shell is rc (with readline), because it does not get in my way. No quirky highlighting, no pseudo-intelligent (wrong) auto-completion, no integration of VCSs I don’t even use, a decent scripting language for (e.g.) performing commands on a list of files.

For scripting, I usually use bosh from the schily tools, because it aims to be 100% POSIX-compliant (= portable), but I really don’t write many shell scripts - the language is ugly and hard to maintain.
 
For an interactive I like zsh just because it has some niceties (themes, completion, etc) that mean I don't have to hunt or research much of anything - I don't use any of the fancy scripts people add to it with all kinds of weird git stuff.

For scripting, wherever possible I just use plain sh (my dev env is using busybox sh, which I believe is the same or similar to to dash) but when things get a little complex I use bash, once that begins to get complex I start using python and once that begins to get complex I reconsider if what I am trying to do is worth it.

On freebsd I always used (t)csh although my zsh config and personal scripts that I use instead of aliases goes together so nicely now that I'd use zsh on freebsd for interactive shell.
 
been using tcsh for a heck of a long time on interactive sessions, sh/bash for programming.

As for a bang in tcsh/csh, escape it with a backslash.
 
I'm a long-time GNU/Linux user, so I tend to use bash, also on FreeBSD.

Although, the login shell for my FreeBSD root account is /bin/sh.

I don't mind at all writing relatively simple or short programs in shell script (bash), and I think that makes sense. But once it gets complicated or needing to talk to a database, I switch to python.
 
I use fish
 

Attachments

  • what_is_your_favourite_shell.jpg
    what_is_your_favourite_shell.jpg
    37.1 KB · Views: 92
In FBSD I use zsh as interactive shell and sh for scripts, when the script get to complicated I move to perl.
I also use oksh on OBSD and I like it (only on OBSD).
 
bash

Can't do zsh, which I would prefer for interactive functionality. But I have libraries of shell code fragments that I use both in scripts and interactively - and the syntax incompatibilities between Posix sh and zsh make that impossible.

I also find bash to be pretty bug free for a program of its size.
 
Bash. Because about 15 years ago, it was the default on the Linux machines that I didn't (want to) administer, available on all OSes, and it works fine. And on my FreeBSD machines, I can easily install it. Today, it's even the default login shell for root on my FreeBSD machine (I do keep alternate accounts with /bin/sh and tcsh around).

I hardly write significant shell scripts. If it gets to be bigger than 20 or 30 lines, it gets moved to Python or Perl.

I could switch to zsh; it would have advantages (I think MacOS likes it better), but for now bash works fine.
 
IMHO, there's no reason at all to use anything else than what your OS provides as /bin/sh for scripting (and yes, if strictly sticking to POSIX/bourne with scripting isn't enough, you really might be better off to use some "real" scripting language instead).

Leaves interactive shells. So far, the thread shows more or less what I expected:
  • Some like tcsh, most likely because a C shell comes with BSD "by tradition" and tcsh offers some nice interactive features.
  • Some want POSIX/bourne compatibility, then the choice seems to be either bash or zsh (I personally prefer zsh...)
  • "Exotic" shells (like fish) are a minority
 
shells/fish all the way. Yes, even for root. But I admit that I'm currently playing arround with plain /bin/sh as my interactive shell. Just to see how viable it is. And yes, I could live with it. Would be nice to have, if the prompt wouldn't drop zero-sized escape sequences, so the prompt could have some color or newline.
 
For FreeBSD I tend to use bash. It still does work surprisingly well for typical popular GNU software.

That said, the inevitable GNU and/or Linux bloat is starting to appear. It is almost unusable on many Linux distros because of autocomplete plugins calling into programs to find argument lists. Plus if a program is missing, it scans the package repo to ask to install it. These kind of "unexpected" plugins are pretty messy and slow, breaking workflow.
 
Z shell (Zsh) because and I'm using it from a long time (when Arch GNU/Linux init behaved like a BSD-style one) and old habits die hard, but for scripting I'm using sh(ash) to keep as POSIX compatible as I can.
 
Any tcsh gurus ( mer ) on this thread want to explain how the following loop works?

C-like: 
  set v = `myfile.txt`
  set i = 1
  while ( $i < = $#v )
  echo $v[$i]
  @ i = $i + 1
  end

The outcome is to echo each line of the text file. Looks to me like it is creating an array and looping through the array index. In particular I can't find andyreference to what "$#v" means but it seems like it should represent the number of lines in the file.
 
Not sure if that's csh/tcsh syntax.
first the backticks on set v = typically mean "execute this command" and would set v to the output of the command.

if you change that line to:
set v = `cat myfile.txt`

Then it sets v to the contents of myfile.txt
Typically $# is "number of arguments, the $#v is "number of arguments in v"

If myfile.txt has:
one
two
three
four
five

it prints 5 lines

If it has:
one
two
three
four
five six seven

you get 7 because whitespace is the default delimiter.
 
I just use whatever shell the OS vendor provides. Usually this is /bin/sh, which is also what I prefer for scripting. I figure the OS vendors know what they are doing. All these shell scripting languages are basically the same to me anyway.
 
mer said:
Not sure if that's csh/tcsh syntax.
first the backticks on set v = typically mean "execute this command" and would set v to the output of the command.

if you change that line to:
set v = `cat myfile.txt`

Then it sets v to the contents of myfile.txt
Typically $# is "number of arguments, the $#v is "number of arguments in v"

If myfile.txt has:
one
two
three
four
five

it prints 5 lines

If it has:
one
two
three
four
five six seven

you get 7 because whitespace is the default delimiter.
Click to expand...
You are absolutely right. I forgot to include "cat" in set v = `cat myfile.txt`. This loop strategy was recommended as a way to sequentially feed a list of arguments to a command from a text file and I have to say it worked very well. I am sure with a huge file there would be a risk of crashing due to slurping the whole file at once into memory as opposed to reading the file a line at a time as can be done in bash with readline. At that point probably a perl or python script would make more sense though.
 
Not sure if this is a tcsh thing or a find thing but the behavior was unexpected ( for me anyway ).

Code: 
> cd /usr/ports
> find . -type d -name fish*
find: No match.
> find . -type d -name *fish*
find: No match.
> cd shells
> ls
../                                heirloom-sh/                       rc/
./                                 ibsh/                              rubygem-shellwords/
44bsd-csh/                         ion/                               rush/
Makefile                           jailkit/                           sash/
anongitssh/                        klish/                             scponly/
antibody/                          ksh-devel/                         starship/
ast-ksh/                           ksh/                               switchBashZsh/
bash-completion/                   ksh2020/                           tcsh_nls/
bash-static/                       ksh93/                             tcshrc/
bash/                              mksh/                              v7sh/
bashc/                             modernish/                         viewglob/
bicon/                             nologinmsg/                        vshnu/
bosh/                              nsh/                               wcd/
ch/                                ohmyzsh/                           xonsh/
dash/                              oksh/                              yash/
elvish/                            p5-Bash-Completion/                zsh-antigen/
envy/                              p5-Shell-Perl/                     zsh-autosuggestions/
es/                                p5-Term-Bash-Completion-Generator/ zsh-completions/
etsh/                              p5-Term-ShellUI/                   zsh-navigation-tools/
fd/                                pdksh/                             zsh-syntax-highlighting/
fish/                              pear-PHP_Shell/                    zsh/
git-prompt.zsh/                    psh/
 
avner said:
Not sure if this is a tcsh thing or a find thing but the behavior was unexpected ( for me anyway ).

Code: 
> cd /usr/ports
> find . -type d -name fish*
find: No match.
> find . -type d -name *fish*
find: No match.
> cd shells
> ls
../                                heirloom-sh/                       rc/
./                                 ibsh/                              rubygem-shellwords/
44bsd-csh/                         ion/                               rush/
Makefile                           jailkit/                           sash/
anongitssh/                        klish/                             scponly/
antibody/                          ksh-devel/                         starship/
ast-ksh/                           ksh/                               switchBashZsh/
bash-completion/                   ksh2020/                           tcsh_nls/
bash-static/                       ksh93/                             tcshrc/
bash/                              mksh/                              v7sh/
bashc/                             modernish/                         viewglob/
bicon/                             nologinmsg/                        vshnu/
bosh/                              nsh/                               wcd/
ch/                                ohmyzsh/                           xonsh/
dash/                              oksh/                              yash/
elvish/                            p5-Bash-Completion/                zsh-antigen/
envy/                              p5-Shell-Perl/                     zsh-autosuggestions/
es/                                p5-Term-Bash-Completion-Generator/ zsh-completions/
etsh/                              p5-Term-ShellUI/                   zsh-navigation-tools/
fd/                                pdksh/                             zsh-syntax-highlighting/
fish/                              pear-PHP_Shell/                    zsh/
git-prompt.zsh/                    psh/
Click to expand...

Shells react differently when a pathname wildcard matches nothing:
- some shells then pass the 'foo*' including the star to the called program
- some shells consider it an error and do not call the program

The latter behavior can be surprising but is arguably safer.
 
You must log in or register to reply here.
Back
Top