Your favorite shell in FreeBSD

  1. Tell about your favorite FreeBSD shell. What opportunities are you most interested in?
  2. How many lines does your shell configuration take? This question is because I saw monstrously complex .shrc in someone's dotfiles on github.
  3. Does anyone use csh in FreeBSD 14 for a non-privileged user or even for root (which is contrary to the recommendations in the third paragraph of the "Default Shell" paragraph?
  4. Why was sh(1) chosen by default in FreeBSD 14.0? What was the rationale behind the decision to change the default shell from csh(1) to sh(1)? Do you support this decision or criticize it?
  5. Which default shell do you consider more historically and conceptually justified for FreeBSD?
UPD: Forgot one more question. 6. Do you use vi-like control using bindkey -v? How does this correlate with your favorite editor? For example, I love Emacs, but on the command line I prefer vi-like controls in csh.
 
  1. I like tcsh(1). Got used to the different style (compared to any of the 'bourne' like shells)
  2. It's mostly the default, only added a bindkey for <DEL> key and some aliases and EDITOR set based on whatever is found first, nvim, vim or the plain vi.
  3. tcsh(1) yes, csh(1) and tcsh(1) are actually the same executable (hardlinked) but have slightly different properties. As I said with 1. I got used to it.
  4. It was chosen because csh/tcsh messed up when people copy/pasted 'bourne' shell syntax. I get the reason why it was changed. Left all my own systems on csh(1), because I'm used to it being there.
  5. That would be csh(1), but again, I understand the switch. The sh(1) of FreeBSD has been much improved recently. Many new features (mainly specific to 'interactive' use) didn't exist for a long time.
 
csh and maybe tcsh for my users. I don't touch the rest.
 
  • Thanks
Reactions: dnb
It was chosen because csh/tcsh messed up when people copy/pasted 'bourne' shell syntax.
So the shell change is largely justified by the desire to be closer to people? Not to be so canonical and orthodox?
tcsh(1) yes, csh(1) and tcsh(1) are actually the same executable (hardlinked) but have slightly different properties. As I said with 1. I got used to it.
On FreeBSD 14, csh(1) lives in /bin/csh rather than /usr/local/bin/csh. Therefore, we can ignore this warning? Right?
Code:
After installing another shell, use chsh(1) to change a user’s default shell.
It is recommended that the root user’s default shell remain unchanged since
shells which are not included in the base distribution are installed to
/usr/local/bin. In the event of a problem, the file system where
/usr/local/bin is located may not be mounted. In this case, root would not
have access to its default shell, preventing root from logging in and
fixing the problem.
 
I use Bash on all my systems because I'm lazy and prefer typing `cp /etc/foobar{,.bak}` instead of `cp /etc/foobar /etc/foobar.bak`
 
  • Thanks
Reactions: dnb
On FreeBSD 14, csh(1) lives in /bin/csh rather than /usr/local/bin/csh. Therefore, we can ignore this warning? Right?
Well, don't confuse /bin/csh and /bin/tcsh (part of the base) with shells/44bsd-csh.

Originally BSD came with the C-Shell. At some point in history that original C Shell was replaced with tcsh, which is essentially a modified and extended C shell. Similar to how bash became a newer and extended version of the Bourne shell. And similar to bash, tcsh is backwards compatible with the original C shell. On FreeBSD they are the same executable:
Code:
dice@fbsd-test:~ % ls -ali /bin/csh /bin/tcsh
157884 -r-xr-xr-x  2 root wheel 442816 Nov 18 16:33 /bin/csh
157884 -r-xr-xr-x  2 root wheel 442816 Nov 18 16:33 /bin/tcsh
And on some Linux distributions /bin/sh and /bin/bash are also the same executable. They sort of shift features depending on how they're invoked.

6. Do you use vi-like control using bindkey -v?
Primarily use a vi/vim like editor but on the command line I primarily use the cursor keys. The cursor keys always felt more intuitive coming from a C-64 and Amiga (which also had cursor keys). One of the reasons why I liked csh/tcsh was the way the history worked. It does a backwards search by default. Just type the first couple of characters of the command and press the <up> key, I am so used to that now. Bash can be configured similarly but doesn't feel the same and is certainly not configured by default that way. The original /bin/sh of FreeBSD had very little command history, certainly no persistent history. So tcsh was just a better interactive shell to use that was always available.
 
1. - 3.:
tcsh for user, csh for root.
also on 14
I neither have the will nor see the need to change, cause I'm used to those for many years,
can do everything I need to do with a shell (except scripting), have my configured .cshrc and history for many years, am used to its UI and syntax, and would be pissed if I'm forced to change.

Under sh/bash most things are not only differet but seem a bit more complex, and complicated to me.
If I'm "accidently" in a bash I get pissed in no time, just because I'm not used to its behaviour, and I'm not willing to learn it, as long as I can use (t)csh.
I don't see why to use a more complicated way, or even change it for no reason, when all I need can be done with the tools I already have and am used to.

My .cshrc has 123 lines - at the moment; besides my wm .config it's one of those config files I edit regulary to fit my needs.
It's the original default one I modified:
the aliases for ls, pager, and editor, the prompt, and added several aliases myself.

If I'd take a peek to another shell I was interested in zsh.

Except scripting:
All my shell-scripts have a shebang to use sh/bash, of course.
When I started to learn scripting I tried the obvious: scripting in csh - bad idea (at least to me.)
Learning to script in sh/bash can also be a real brain teaser, because of its special syntax you may not be used to by any programming language you may learned so far, different ways of quoting, and other things (look out for the differences of sh and bash; traps).
But in my eyes I cannot see a real purpose for preferring scripting in csh over in sh/bash.
I'm sure there are users doing scripting in csh, but personally I don't know one.

4. I don't really know; I presume "Linux-world" won, cause there bash is standard. NO!! just kidding!
sh is the new root (login) shell on 14, not bash, I know.
As far as I know historically sh is the orignal unix-shell.

5. As I said, for (AT&T) unix it's sh, but for BSD it's csh, as far as I know.
 
  • Thanks
Reactions: dnb
On FreeBSD:
- ZSH for normal use​
- SH for root​
On OpenBSD I use OKSH for everything.
On Linux I use ZSH for everything.

For scripting I use:
Code:
#!/usr/bin/env sh
in all OS`s.
 
ksh93 since about forever.

I try to keep my .profile and .kshrc fairly short, they are something like 50 and 20 lines respectively.

keybindings:
set -o emacs
because that's what I'm used to
 
  1. Tell about your favorite FreeBSD shell. What opportunities are you most interested in?
sh(1) for scripting, shells/bosh for portability testing and shells/zsh for interactive use. Interested in POSIX compliance in general and comfortable features for interactive use.

  1. How many lines does your shell configuration take? This question is because I saw monstrously complex .shrc in someone's dotfiles on github.
Close to none, I use premade things like oh-my-zsh or spaceship-prompt, depending on the needs.

  1. Does anyone use csh in FreeBSD 14 for a non-privileged user or even for root (which is contrary to the recommendations in the third paragraph of the "Default Shell" paragraph?
  2. Why was sh(1) chosen by default in FreeBSD 14.0? What was the rationale behind the decision to change the default shell from csh(1) to sh(1)? Do you support this decision or criticize it?
I waited for that a long time. csh is non-standard. Some things just won't work by (ill) design (working with file descriptors is a classic example). The original C shell was also riddled with obscure and annoying bugs. FreeBSD's tcsh(1) is an enhanced/comfortable and bug-fixed C shell, so if people like it, nothing wrong with that .... but of course, the incompatibilities with POSIX (derived from bourne shell) and the special limitations remain. The general recommendation is to never use a C shell for scripting but only for interactive use. This makes sense. I personally don't want to remember two different sets of syntax though, so I want my interactive shell to be based on POSIX/bourne as well.

The only reason FreeBSD has a C shell in base in the first place is that it's a traditional shell on BSD systems.

  1. Which default shell do you consider more historically and conceptually justified for FreeBSD?
Talking about defaults, I don't see anything like "historical justification". If you don't like defaults, change them. Conceptually, for a modern OS oriented at POSIX-compliance (no, FreeBSD is most likely not strictly compliant, but it's close enough), a POSIX-compliant default shell makes most sense.

UPD: Forgot one more question. 6. Do you use vi-like control using bindkey -v? How does this correlate with your favorite editor? For example, I love Emacs, but on the command line I prefer vi-like controls in csh.
I only use editors/vim as an editor. I typically configure my commandlines to vi mode.
 
  • Thanks
Reactions: dnb
bash for interactive use in my non-root user account.

I would like to have some of the advanced zsh features, but zsh is slightly incompatible with bourne shell syntax, namely in default word splitting. I have extensive libraries of functionality in bourne shell that I use both in scripts and interactively - so I need a fully compatible interactive shell.

I also found that bash is very bug-free, and zsh less so when I made those choices. That is a long time ago now, can't say whether zsh has bugs that would bother me now.
 
  • Thanks
Reactions: dnb
bash, sh anything you can posix script directly on the command line, preferably with emacs key bindings and history
i never bother to change root shell
for scripts just posix (sh)
 
for scripts just posix (sh)
Although sh(1) is still somewhat minimal, it already does significantly more than POSIX requires/specifies...

That's mostly a good thing (e.g. there are some "interactive comfort" features, some of them added more recently, that make it suitable as root's default shell), but can bite you if you rely on it to check conformance of your scripts.

An obscure issue I recently discovered testing with pbosh(1) (from shells/bosh) concerned a script using character-by-character string processing. The only ways to do this in POSIX sh are either rest = ${foo#?}; char = ${foo%"${rest}"} or char = $(printf %c ${foo}); rest = ${foo#"${char}"}, and unfortunately, both approaches actually work on bytes, not on characters. While it always works with sh(1), pbosh(1) just fails to chop off anything in a UTF-8 locale for characters > 0x7f (which then lead to a nasty infinite loop). I can only assume that's because a single byte >0x7f is never a valid character in UTF-8. The solution here was a temporary switch to the only locale guaranteed by POSIX: "C".
 
Favorite shell, perhaps mksh. This for users, but not for root, because root needs to be one which comes with the operating system, so it uses the customization file, and that I could use it without needing rescue mode.

For root, I use sh, but I used to use csh there. Most utilities I need for users is with mksh. sh lacks features and consistency of them, while it's now better than it used to be. I may go back between sh and csh for root, because both come with the base install.

I used to use csh for all of my users, except for the default of sh for scripts. A major issue for me, aside from having a different syntax, is that csh has different configuration settings than the Bourne shells.

sh has some autocomplete features now, but it's still primitive. When I don't use root a lot, and can use doas from my user account, it's enough for a lot of purposes. One issue with sh in root, is I have to sh into it again, in order to use my configuration features. Until it gets improved, csh is ok to fall back on.

mksh should come with the base install of FreeBSD, and unless sh gets improved, be the default for root.
 
ZSH - configured this way:

- https://vermaden.wordpress.com/2021/09/19/ghost-in-the-shell-part-7-zsh-setup/

zsh-fish-completions.png


With coloring of fish(1) shell ... while having the POSIX compatibility.
 
  • Thanks
Reactions: dnb
ZSH - configured this way:

- https://vermaden.wordpress.com/2021/09/19/ghost-in-the-shell-part-7-zsh-setup/

zsh-fish-completions.png


With coloring of fish(1) shell ... while having the POSIX compatibility.
I like your approach. But I couldn't understand whether you use zsh for root as well as for a non-privileged user? Do you run commands as root or do you prefer sudo?

After all, it is extremely inconvenient to change the shell depending on the user. At the same time, using zfs as root is not recommended.
 
Probably nothing that hasn't been said (here or elsewhere):

Of the shells in the base system, tcsh(1) is clearly superior for interactive usage, while sh(1) is for scripting. I try to make all of my shell scripts POSIX-compatible (often checked with devel/hs-ShellCheck). If a scripting task is difficult or impossible with sh(1), then it's probably easier to implement in another language than in a shells/bash script.

Of the non-indigenous shells, shells/zsh is absolutely outstanding for interactive usage (and I am now thinking of switching back to it from tcsh(1)). Especially tcsh(1) autocomplete feels very limited by comparison. shells/bash is obviously a Linuxism and by now I am occasionally disappointed to see as a dependency in a port. Heck, even MacOS is now on zsh by default.

It was chosen because csh/tcsh messed up when people copy/pasted 'bourne' shell syntax. I get the reason why it was changed. Left all my own systems on csh(1), because I'm used to it being there.

I do see this rationale for switching to sh(1). Coming originally Linux and MacOS, I was a bit baffled by the behaviour of tcsh(1) when I first installed FreeBSD (12, I think). Still, in a perfect world, every advanced user probably ought be comfortable with both of the native shells to a certain extent.
 
Back
Top