FreeBSD switches the default root shell from csh to sh | Hacker News Reader

FreeBSD switches the default root shell from csh to sh

cgit.freebsd.org

157 points0mp148 comments

We once upgraded a major research department from csh to tcsh (while also migrating most users to bash). A senior leader complained that when they hit the up arrow, the last command they typed showed up.

I explained how to disable readline

That says a thing or too about habits. Was he pissed or was it just a light comment ?

I'd be sad to see an educated person refuse interesting new tricks (readline causes no regression or loss right ?)

he was pissed! and, really didn't like terminal colors when you ran 'ls' (so I showed how to unalias ls)

At this point I don't want to learn any new tricks, either. I'm sticking with bash for the rest of my life.

what kind of research ? was it computing related or something really different ?

I'm quite shocked

I'm not 20 something either, I'm not chasing new shiny.. but a simple history access (arrows or search) is not an invasive disruptive toy feature..

alas

biomedical research, but the person I was helping "had written a kernel disk driver for VAX BSD back in the 80s" and I think they wanted things to more or less stay the same as BSD in the 80s. Which, as far as wishes go, isn't terrible.

yeah I guess he earned the right to have his ways :)

I've been trying to stick with bash for at least 20 years (I did have a brief tcsh phase before that) since a time when sticking with it meant having to install it on every unix system I touched. However, now that MacOS defaults to zsh, I'm starting to wonder if I should summon up the effort to change again.

I think the most noticeable difference is that `$foo` doesn't word-split unless you do `${=foo}`. Beyond that, I don't think one would notice they were using zsh instead of bash. In most ways, zsh is pretty much a superset of bash.

personally, I don't have interest in zsh because bash is the default shell in Linux, which is the UNIX system I use (I find mac's unix to be really a weird variant). Mac switching to zsh is just more evidence they're diverting from the mainstream.

> I find mac's unix to be really a weird variant

It's closer to BSD than it is to Linux. Not super similar, but closer, especially in ways one tends to notice on the command line.

It still sticks pretty close to BSD. I am seeing a ton of (entirely natural) similarity since I started seriously playing with FreeBSD

you're right, Mac OS X is a derivative of BSD but it also has significant Mach tech (like the linker).

I've used freebsd for years and I still find Mac OS to be the least useful UNIX.

Ironic it's one of the few (only?) popular, widely deployed ones left that gets to sport the fact it's a certified Unix OS - https://www.opengroup.org/openbrand/register/

Sort of. I see this a different way. Many years ago, Linux replaced UNIX as the "standard UNIX", and certification become irrelevant.

Further, unless I'm missing an important technical detail, Linux could, with some effort, pass the certification process.

Apple switched to zsh because newer versions of bash are licensed under GPLv3.

I know what the reason is. I don't care. I use GPLv3 and have no interest in an OS that doesn't. You can run bash on windows or compile it yourself on any platform. microsoft even distributes it with windows.

Not strictly correct. It's provided by whatever WSL distro you download, and that download comes from the distro as opposed to Microsoft.

Compile it yourself on MacOS, problem solved. Or install it with Homebrew?

IIRC, MacOS had to ship with a fairly old version of bash by default because newer versions have a more copyleft license; I always assumed that their swap to zsh was because they wanted something both up to date and compatible in terms of the license (and the fact that most bash "just works" when you run it in zsh is a plus).

macOS is about as standard of a Unix as you can get, apart from Linux with coreutils.

I would guess that he was mostly pissed that things "just changed" without being asked. While these sort of things like the up arrow seem like a no-brainer to many here, showing up for work on Monday and having everything just be different sucks. It's a bad experience, and I can't really blame him for being annoyed.

A lot of times people would be a lot more receptive if you show them "hey, you can use the up arrow like so if you want!" Then they can choose and adapt at their own pace if they want to, and they're in control of their own systems.

I told him (this guy was the chair of the informatics department at a major biomedical company) that I understood if he didn't like color ls, because it could be hard to see some colors on a terminal, but that if he wanted to disable arrow key history he was just crazy. Some things are just progress.

It's delicate. The noob me chased after new tricks with much more enthusiasm than the current me. Over time, priorities change, and now I just want to get stuff done and for tools to get out of the way. I'd appreciate new tricks that bring quite a lot of benefit to my workflow, but the little tricks I'd rather let fly past me.

If the tools such as base environment changes way too often, I'd be annoyed as well - not because I don't know how to make the colours go away or set up the proper aliases - but the fact that I need to do it and pause my actual work.

I totally understand that, I'm not a young mind anymore, and I get that most of these are pointless superficial tricks. I spend most of my days venting about the state of computing (especially since web2.0 came and replaced a lot of stuff with bloated regressions in many offices)

But I considered readline a good addition, not a waste of time and neurons.

ps: I stopped using zsh/fish, my emacs theme is the vanilla theme.. you forget about these 'improvements', for real tasks they don't matter.

I work half as fast without fish completions. matters to some people

Fish truly is superior for productivity.

It has its downsides unfortunately.

Maybe I shouldn't have included this comment after the `pointless superficial tricks` :)

It is one of the saddest self-realizations in my old age that I am no longer excited about learning/perfecting my tools.

But as you say, tools must get out of the way...

As always, there's an xkcd on this

https://xkcd.com/1172/

I wonder what he was using the up arrow key for in the shell.

In those days people mainly used ! expansion. https://en.wikipedia.org/wiki/C_shell#History. I know many people who are incredibly good at using ! expansion to edit previous commands ("change that command 5 lines ago to rm -rf this other folder") but it's a bit of a footgun.

Right, but the up arrow didn't get in their way, right? So why get mad?

I imagine that how it worked for them before is that the up arrow would move the cursor to the previous line into the output of the previous command, while feeding the arrow key escape sequences to the shell prompt as part of the command. IOW, a pretty useless and annoying key right? Why even press it? How did they notice readline?

from what I can tell he was looking hard for problems.

He also noticed that if you ran 9 "yes" commands on a 8 core machine, the CPU wasn't allocated in 8/9ths units (one process always got a lot less CPU). he was used to much more predictible CPU scheduler on multiprocessor systems (spoilt by TruCluster). Linux later adopted a better scheduler (fair share) so imho he was right on that one, even if "yes" is a terribly performance metric.

It seems the lesson here is that changing things out from under someone isn't a good look. What would have been the cost in not changing users' shells for them?

Everybody else has a worse shell.

Depends how you use it.

If you just want to execute it then it is a footgun - using only the !command syntax.

If you use the !command:p syntax then you are just printing what command has been executed instead of invoking it.

Example.

    % uname
    FreeBSD
    
    % !uname
    uname
    FreeBSD
    
    % !uname:p
    uname
    
    %

Doesn’t the up arrow key show the last command executed?

Why do people care what their default shell is, when you can just “exec csh” immediately upon logging in?

Was this kind of shell changing disabled? Maybe there’s no way of doing that exec automatically? Is there some advantage to having your shell of choice explicitly listed in /etc/passwd?

There's a long list of boring answers you probably don't care about involving "these are biomedical researchers using UNIX, not hackers", "complex legacy scripts that depend on default shells", and "enterprise compliance".

The second two sound quite interesting. I hadn’t thought about those at all.

In my view all shells are quite good (for a given value of good).

If you have a problem with one or two shells but not all of them, then you might want to look within.

In the recent history sh(1) has gain the missing features for it to become a usable interractive shell:
- command completion

- ...

Too much bloat for my tastes.

Doesn’t command completion cause a disk scan? Which can be a problem if the system is failing in some way and you’re trying to recover.

Can you not just avoid activating a completion attempt if you are in that scenario?

I think it is not as easy as you imply, especially if it is bound to muscle memory.

Side note: https://www.google.com/search?q=don%27t+say+just

What percentage of your time do you spend on a shell on a host where the disk is failing and tabbing could cause a catastrophic disk read vs being on a perfectly healthy system where tab complete is a nice feature?

What percentage of your time do you spend logged in as root? ;)

unless you're exclusively running shell built-ins, doesn't running any command at all potentially cause a disk scan

Usually the shell creates a cache of commands on start, which can be refreshed with `hash -r`.

As far as I can tell the hash table is initially empty after you first start the shell. At least, that's the case for bash.

  $ hash
  hash: hash table empty

Reminds me of the times I've had run out of space in a Linux system. When you SSH to the system and press TAB for command completion, all you get is some message regarding "the system running out of space".

Maybe in sh type shells. In csh/tcsh commands are hashed, so command completion is in memory. Thus the need for rehash.

There is a new setting in tcsh to allow for automatic rehash, but I have it disabled.

hash -r in bash. No idea if there's a setting, I'm too used to doing the rehash as required to've noticed if there was.

What's the harm?

I'm guessing your alternative is:

  echo $PATH | sed 's/:/\n/g' | xargs ls | grep command_im_looking_for

Additionally, an empty element in this context means $PWD

Can install dash from ports collection. Should work fine as scripting shell in place of this one.

I would avoid this for root.

I mean, preferences are preferences but you can hardly call command completion 'bloat'

I assumed this was sarcasm and I am surprised to read all the serious replies.

A die-hard tcsh user myself, I mourn the end of an era, but has anyone done serious scripting in the C shell? I jokingly call it a sin in the eyes of the LORD, but seriously, it really, really sucks compared to even just the POSIX shell. It's probably time for me to finally give into Bash or zsh or something equally modern. Might be nice to get access to all of those shell completion hooks some tools have—not because tcsh doesn't offer custom completions, but because most tools don't target it. And so it goes.

The surprisingly-"smart" completions are the only thing I really notice about zsh vs. bash, but AFAIK you can add the same functionality to Bash if you like. Ditto the git-related prompt modifications, like showing the current branch or whether your working dir is dirty, which is kinda nice—you can configure that sort of thing in bash, as well.

You can do all kinds of fancy stuff with zsh (especially via something like oh-my-zsh) but it bloats it and slows it down too much for my liking. Maybe if I were trying to work on a machine with no GUI, I'd go for that sort of thing. As it is, I don't need a battery level graph or load monitor or whatever, always visible in my terminal.

It's a sad state of affairs that when people think zsh they think "battery status".

The most important thing about zsh you should think of is "no need to quote variable expansion".

Even back when most people I knew used tcsh interactively, any significant scripting we did was for korn shell. It's been so long I don't remember what would have been so bad about tcsh scripting, but since we all made that choice I assume we would have agreed with you.

Tom Christiansen's essay "Csh Programming Considered Harmful" was commonly passed around the early internet and lists all the reasons why scripting in csh is terrible. I always considered csh purely for interactive use (where it was light years ahead of sh) and switched to ksh (or perl back in those days) for scripting.

http://harmful.cat-v.org/software/csh

I am sad to hear FreeBSD is changing root from tcsh to sh (FreeBSD moved from csh to tcsh a while ago).

It was one of the things that made FreeBSD unique. I guess the got sick of hearing this question: "can I change the root shell to bash ?". I think they were the last holdout of the BSDs.

But to me, if you care what root's shell is, you are doing something wrong by using root way too often.

It is an absolutely trivial thing. Nobody should be making decisions about whether to use FreeBSD based on such trivialities.

That said, it really was damned annoying. I like to port my software to AIX, FreeBSD, Linux/glibc, Linux/musl, NetBSD, macOS, OpenBSD, and Solaris. All of them use a Bourne-like root shell except FreeBSD, and every time I go to upgrade a FreeBSD VM or build a new one I seem to always trip over that at some point. If I used FreeBSD regularly I wouldn't care as much--I'd change the default, or know how to achieve what I want more directly. But not being familiar with FreeBSD, I always end up in a root shell poking around trying to remember how upgrades work, which tools I need to find documentation for, etc, and end up cursing csh for compounding the mental burden.

From my perspective, changing the default root shell is a benefit, albeit very minor. Though, if FreeBSD (and NetBSD and OpenBSD, for that matter) began publishing official VM images, that'd be worth so much more to me.

> if FreeBSD (...) began publishing official VM images, that'd be worth so much more to me.

They do: ftp://ftp.freebsd.org/pub/FreeBSD/releases/VM-IMAGES/

Ready to use simple ZSH setup for the rescue:

https://vermaden.wordpress.com/2021/09/19/ghost-in-the-shell...

> has anyone done serious scripting in the C shell?

I recall SAP created used CSH/TCSH for its scripts but I am not sure they still do it.

zsh + oh my zsh + https://starship.rs/ is my pitch to anyone looking to upgrade their shell.

I am not a freebsd user, been on linux since 1992, but most of the time I read something about freebsd users and it seems like they want to be some older unix, like Solaris or True64 or something.

I expect they want to be FreeBSD. In particular, they are not Linux, and have no need to be Linux, if that's what you're getting at. Certainly I do get a certain amount of Solaris feel from them; they ripped a decent amount of tech out of OpenSolaris (yay dtrace and ZFS) and BSDs were always structured more like Solaris than most Linux distros (base system separate from packages, base system created by installing multiple sets/consolidations), but they're their own thing.

EDIT: Oh, and I would expect BSDs to feel a lot more like traditional unix because they're direct descendants of UNIX™, unlike the later clones like GNU/Linux.

SunOS was a BSD before it turned into Solaris, a System V

FreeBSD _is_ a Unix, being derived from the BSD Net-2 release in the early 1990s.

GNU and Linux distributions are actually Unix clones, with different distributions mimicking or incorporating code from the various open source and proprietary Unix operating systems. For example, Slackware used to use an rc-style init system like BSD. Linux cgroups (underlying tech like Docker) look very much like Solaris zones. GNU coreutils have POSIX compatibility modes. Systemd looks a lot like Solaris SMF. Stuff like ZFS and DTrace were imported from OpenSolaris. And so on.

>FreeBSD _is_ a Unix

That's a common misconception. It's as much of a UNIX as Linux is (see the AT&T lawsuit).

https://en.wikipedia.org/wiki/Ship_of_Theseus

I used FreeBSD in production for years as a hosting platform, starting in the late nineties. Then it had an earned reputation as being more secure, stable and higher performance than Linux. Yahoo and other large services were using it for their servers as well. Since then Linux has improved, but a diverse ecosystem of options is healthy. A monoculture of OSes would be vulnerable to global security problems just a diet based on only one crop.

It's great that other projects make other choices about default shells and other system design details.

Pre-1992 it was SunOS and yes that is exactly what we want (without all the security holes).

SunOS was BSD and Nirvana as far as Unix goes. Solaris was SysV and quickly earned the nickname "Slowlaris". For me FreeBSD is the functional descendant of SunOS.

As for Linux I first tried it out in 1993 and was appalled that command line switches for most standard Unix utils had been arbitrarily remapped. Tried FreeBSD 1.0 when it came out and never looked back. Of course I use Linux in AWS and various servers at work and regularly experiment with Linux distros on personal machines but it always feels a bit "off".

I wonder how many other greybeards that cut their teeth on SunOS prefer FreeBSD over Linux today?

> I wonder how many other greybeards that cut their teeth on SunOS prefer FreeBSD over Linux today?

That could be an interesting question. I certainly cut my teeth on SunOS and Irix. I much prefer modern Linux.

I think the Slowlaris moniker was not due to Solaris itself, but the speed of their SPARC processors. I used to work very closely with x86 Solaris for financial trading and it was performant (and stable!) on Intel hardware at the time (circa 2010). At the time Solaris 10 was feee as in beer. When Oracle took over they got rid of this and wanted $1K per CPU socket per year on non Sun/Oracle hardware. Needless to say everything went to Linux rather quickly.

I do prefer FreeBSD over most Linux distros (except Slackware) from a philosophical standpoint.

It wasn't just old hardware. Upgrading from SunOS to the early Solaris versions on the same hardware was noticeably slower. 2.4 was the first usable version IMO and it improved a lot by the time 2.6 was out (but then they dropped support for older hardware).

The Slowlaris name is much older than that, going back to when they made the switch from BSD to System V in 1991. You could install either the retroactively named Solaris 1.x versions or the new 2.x on the same hardware, and everyone noticed that the new OS was much slower.

I am not sure when Slowlaris term was introduced but I tried OpenSolaris many times on the same hardware that I run FreeBSD and it felt slower for each task ... from the boot process to typical tasks involved.

But I always liked SUN Solaris for its features and solutions.

Slowlaris: /slo'�lahr�is/, n.

[Usenet; poss. from the variety of prosimian called a “slow loris”. The variant ‘Slowlartus’ is also common, related to LART]

Common hackish term for Solaris, Sun's System VR4 version of Unix that came out of the standardization wars of the early 1990s. So named because especially on older hardware, responsiveness was much less crisp than under the preceding SunOS. Early releases of Solaris (that is, Solaris 2, as some marketroids at Sun retroactively rechristened SunOS as Solaris 1) were quite buggy, and Sun was forced by customer demand to support SunOS for quite some time. Newer versions are acknowledged to be among the best commercial Unix variants in 1998, but still lose single-processor benchmarks to Sparc Linux.

> I wonder how many other greybeards that cut their teeth on SunOS prefer FreeBSD over Linux today?

Not a greybeard but I certainly reach for a BSD when I want to "use Unix".

Linux is a quivering basket case that cant decide if its Unix, MacOS or Windows.

> Linux is a quivering basket case that cant decide if its Unix, MacOS or Windows.

A more positive spin on this would be that it combines the best of all three.

Personally I'm very much in the Unix camp though, and have the proverbial greybeard long enough to trip over. But I can see the value in the "Linux way" of doing things. Actually, I mostly just use Linux myself these days, mainly because of software compatibility and because it's "Unix-y enough" with the right distro; a decent trade-off.

>A more positive spin on this would be that it combines the best of all three.

A more accurate spin would be that it does a half-assed job of implementing features from each but runs off half way to chase after some other shiny feature.

That's the virtue of BSD; it's simple, it's documented it's complete (in features and feature implementation).

I want it to be a more-simple Linux without so many competing choices or moving parts, and it largely succeeds on that front.

Naw. FreeBSD feels like a cohesive whole, if that makes sense. All the basic stuff in it all work together. Comparatively, Linux is a pile of parts strapped together with tape.

Plus the documentation for FreeBSD is much, much better. For one thing, no pushing me to use that god awful “infodoc” crap.

BSDs are UNIX.

https://www.amazon.com/Design-Implementation-FreeBSD-Operati...

Well, GNU's Not UNIX after all...

>"This changes also simplifies making tiny freebsd images with only sh(1) as a shell"

What's the current process to make extremely small "minimal" freebsd server install?

Is it Nanobsd[1], because the unfortunate downside is that the base can't change (I realize that's a feature) and for a web server or database server that might not be ideal.

[1] https://docs.freebsd.org/en/articles/nanobsd/

As a semi-curious non-FreeBSD user, is 'sh' on FreeBSD the Almquist shell or something else?

Yes, it's ash:

https://cgit.freebsd.org/src/tree/bin/sh/TOUR

So am I reading correctly that they wanted to use sh for a while, and it just finally got needed features? This message says "what" but not "why", and while as a user I prefer sh over csh:), I'm curious why the project switched.

A POSIX-compatible shell like `sh` is a given. `csh` is not POSIX-compatible. By dropping `csh`, the the base system could be smaller. Since the usability of `sh` has improved, it was considered worth switching.

On top of that, most people expect syntax somewhat similar to Bourne shell and tcsh is far from such. Its for loop syntax is especially surprising.

I've been a tcsh user for nearly 30 years, but I also believe /bin/sh should be as minimal and reliable as possible, the Bourne shell (or ash), certainly not a bloated monstrosity like bash or zsh. Even ksh is too big for my taste.

csh Programming Considered Harmful http://harmful.cat-v.org/software/csh

That’s outdated, not about tcsh, and mostly nonsense.

I agree csh/tcsh should only be used as an interactive shell, not a scripting one.

Obligatory "CSH considered harmful" by Tom Christiansen around 1995.

http://www.faqs.org/faqs/unix-faq/shell/csh-whynot

Christiansen is correct that it is a terrible programming language.

It's a great shell for user input.

Yes and no; you do run in to problems with that as well, for example trying to get a git branch in your prompt in a performant way that is rather complex. Things like more advanced aliases or completions will hurt your brain (or at least, they hurt my brain), etc. Also: there is no way to get the line number of an error, so made a mistake in your .tcshrc and it's a pain.

I never especially liked that csh-whynot article as I feel it focuses a bit on the wrong things, and things people rarely use in day-to-day usage.

I used tcsh for many years (as it was the default on FreeBSD, the first system where I seriously used the CLI), but I can't really think of many things it does better than either bash or tcsh nowadays. The only thing is that you can set "noclobber" to "notempty" and "ask", but at least "notempty" was added in zsh recently; AFAIK bash can't do that. It's a small but very useful feature for cases where you type "wrong-cmd > foo" and then up and "wrong-cmd-corrected > foo".

Flashback to the SunOS -> Solaris transition.

About damn time.

Whichever shell you might prefer, it's absurd and infuriating to have one shell as the default for normal users (including the first user created at installation time), and a completely different, not even remotely compatible one for the superuser.

Why not just go to Bash or ZSH?

Those are not part of the base system.

And for good reason. If people already call command completion bloat, imagine the uproar if they found out that bash or zsh is built in and the default shell.

FreeBSD is often used as the base for appliances, so some downstream users it may indeed be unnecessary code to maintain. (You perhaps get 'extra' CVEs against your product that may increase maintenance.)

For those with CLI access, adding a more full-featured shell is fairly easy with pkg.

So that it can be maintained in tree

Bash has prohibitive license. What I've heard about zsh is that integrating it with FreeBSD build system would be non-trivial.

Ahh ok. Didn’t know about the license issue. The CVE idea is also very valid. Thanks for clarifying everyone.

The ZSH shell would be actually great choice for shell in the FreeBSD Base System because it uses the MIT license.

As BASH uses the GPL3 license it does not have the chance of being included in the FreeBSD Base System because the FreeBSD project currently tries to remove all GPL3 licensed software from its base.

Details here:

https://wiki.freebsd.org/GPLinBase

Minor nit that we mostly hadn't moved to GPL3 stuff, and now we're working on replacing the remainder of the GPL2 stuff.

zsh isn't POSIX compliant though.

It's not? In what ways?

Keeping more complicated stuff in ports rather than base means users can easily get the exact version they wany so FreeBSD tries to keep base as explicitly a base system.

It's a tradeoff but one I find more useful than not.

So much for the c shell...

The era has gone.

Reply on news.ycombinator.com