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.
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".
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?
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 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.
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.
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).
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.
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?
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".
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.
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.
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.
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.
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.
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.
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?
> 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 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.
[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.
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.
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).
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.
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.
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.
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.
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.
>"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.
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.
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.
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".
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.
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.
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.
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.
I explained how to disable readline