Youngsters squeeing over obsolete tech always reminds me of the scene in Ian M Banks’ novel Excession (set in a semi-utopian galactic empire) where a bored starship crew amuse themselves during a voyage by having the ship’s AI brew up a bunch of ancient diseases and infect them. They enjoy the novelty of sneezing, fevers, vomiting…
This made me smile. As someone who used csh intermittently in the ’90s (Until I started using OpenBSD ~2.2 or 2.3 in ’98 for a couple machines that were mine, I used whatever the local BOFH made available and that was that…) and tcsh for most of the ’00s.
I have to say, though, I didn’t script it much outside of dot files. For anything that might ever see a run outside my personal systems, the shebang was always bourne. For interactive stuff + a great collection of dotfiles, it was my favorite.
But is it? The default shell for new users is ksh, and I don’t recall seeing and csh scripts in base. Everything is either ksh or perl. FreeBSD and I believe DragonflyBSD use tcsh as the default user shell.
Linux® users are often surprised to find that Bash is not the default shell in FreeBSD. In fact, Bash is not included in the default installation. Instead, FreeBSD uses tcsh(1) as the default root shell, and the Bourne shell-compatible sh(1) as the default user shell.
I have distinct memories of csh being the default root shell on previous versions of OpenBSD (DEC Alpha, early 2000s). It struck me because the callback to BSD history, and as a subtle reminder not to do stuff as root…
I also wrote and deleted a semi-sarcastic point-by-point rebuttal to this, but I decided not to post it. I only want to mention that csh arrays are 1-based, like Fortran or (Visual) Basic. For a shell ostensibly “C like” this is particularly jarring.
I used tcsh for about 15 years as my interactive shell, switching to zsh about 2 years ago. I also spent plenty of time answering questions in the csh and tcsh tags on Stack Overflow.
And quite frankly, it’s … not a great shell. I think it’s fine for interactive use, but even for ~/.tcshrc programming it can quickly become awkward. Lack of functions is a big thing; I know you can kind-of work around with it aliases, but it quickly gets unwieldy. It’s also find it hard to debug scripts, since error messages are often cryptic and don’t show a line number.
There are also some good things of course, which is why I used it for so long, but I found that zsh can do pretty much anything tcsh can, and while zsh’s syntax isn’t exactly beautiful it does avoid some of the problems of tcsh.
There’s a good, modern shell inside (t)csh, but it needs a zsh-like cleanup that would be mostly compatible with tcsh, just fixing some of its bizarre limitations and design decisions.
I really like your writing style. But show; don’t tell. I had hoped to see some example scripts, or configuration, or something.
Youngsters squeeing over obsolete tech always reminds me of the scene in Ian M Banks’ novel Excession (set in a semi-utopian galactic empire) where a bored starship crew amuse themselves during a voyage by having the ship’s AI brew up a bunch of ancient diseases and infect them. They enjoy the novelty of sneezing, fevers, vomiting…
This made me smile. As someone who used csh intermittently in the ’90s (Until I started using OpenBSD ~2.2 or 2.3 in ’98 for a couple machines that were mine, I used whatever the local BOFH made available and that was that…) and tcsh for most of the ’00s.
I have to say, though, I didn’t script it much outside of dot files. For anything that might ever see a run outside my personal systems, the shebang was always bourne. For interactive stuff + a great collection of dotfiles, it was my favorite.
I write a lot of csh scripts personally, but that’s from using tcsh and the original csh since the 1990s. I’m still a tcsh user.
But is it? The default shell for new users is ksh, and I don’t recall seeing and csh scripts in base. Everything is either ksh or perl. FreeBSD and I believe DragonflyBSD use tcsh as the default user shell.
Yep not sure how this guy thinks the openbsd people embrace csh/tcsh. root is ksh all the way.
Maybe he’s confusing FreeBSD where csh is the default root shell (not tcsh). DragonflyBSD I’m not knowledgeable to comment on.
According to the documentation,
tcshis the default root shell:I have distinct memories of
cshbeing the default root shell on previous versions of OpenBSD (DEC Alpha, early 2000s). It struck me because the callback to BSD history, and as a subtle reminder not to do stuff as root…I looked into it, and it appears you’re correct. OpenBSD did use csh up until 2005:
https://marc.info/?l=openbsd-cvs&m=111199298104389&w=2
Thanks a lot for taking the time to look into this. I don’t know enough about the innards of OpenBSD CVS to do the research myself.
When is documentation ever out of date? Unless csh is a link to tcsh it shows up as csh.
And csh may have been the default at one point, but that was about 15 years ago which is ages security wise for openbsd. https://undeadly.org/cgi?action=article;sid=20050328171714
Yup,
/bin/cshis a hardlink to/bin/tcsh:Probably easier to see if they were the same inode is what I should have done.
Source agrees with you - https://svnweb.freebsd.org/base/stable/12/etc/master.passwd?revision=339434&view=markup
I was inspired by this to re-read the classic Csh considered harmful. Good stuff.
I also wrote and deleted a semi-sarcastic point-by-point rebuttal to this, but I decided not to post it. I only want to mention that
csharrays are 1-based, like Fortran or (Visual) Basic. For a shell ostensibly “C like” this is particularly jarring.I used tcsh for about 15 years as my interactive shell, switching to zsh about 2 years ago. I also spent plenty of time answering questions in the csh and tcsh tags on Stack Overflow.
And quite frankly, it’s … not a great shell. I think it’s fine for interactive use, but even for ~/.tcshrc programming it can quickly become awkward. Lack of functions is a big thing; I know you can kind-of work around with it aliases, but it quickly gets unwieldy. It’s also find it hard to debug scripts, since error messages are often cryptic and don’t show a line number.
There are also some good things of course, which is why I used it for so long, but I found that zsh can do pretty much anything tcsh can, and while zsh’s syntax isn’t exactly beautiful it does avoid some of the problems of tcsh.
There’s a good, modern shell inside (t)csh, but it needs a zsh-like cleanup that would be mostly compatible with tcsh, just fixing some of its bizarre limitations and design decisions.