Hacker News Reader

Comment by MaxBarraclough | Hacker News Reader

I broadly agree with having courses to teach the topics listed, but:

> Understand shells such as sh, csh, ksh, tcsh, bash, zsh.

I was taught csh as an undergrad. A complete waste of time, in my opinion, akin to teaching BCPL rather than C. Just teach bash, and perhaps sh. To my knowledge, just about nobody writes scripts in csh, ksh, tcsh, or zsh. You use bash for portability across Unix systems, sh for even better portability across Unix systems, or you use a modern scripting language like Python3.

Students may benefit from learning zsh for interactive use, but I don't think there's enough benefit there to justify spending time teaching it.

View on HN

If I had to guess, putting all those shells in the same basket sounds like they're focusing on the universal functionality. Such as pipes and redirection.

That's what I would imagine. I think think shells other than sh or bash are listed more to make students aware of their existence and to reinforce that, in unix, even something as seemingly fundamental as your shell is a self contained tool that can be swapped out for a variety of alternatives.

To extend to your comment, lightly examining a number of shells could also serve a few additional pedagogical functions: * Showing students that there are many shells that they could encounter. * Highlighting the differences. * Showing that there is a long history. * Showing that the history is still alive. * Showing that there is no one right way.

Lots of companies haven't moved on.

In my company the default shell in the UNIX accounts is csh, and tcsh is recommended as a "nicer" csh. They do have bash if you want to use it, but they only "support" csh and tcsh. As a result, many important scripts by engineers are written in csh/tcsh. People who've never used bash. Very annoying, as for those who choose to use bash are often told they have to go into tcsh to get a given program to work, etc.

Most of the places I've ended up working used tcsh (holdovers from Unix days). Both interactively and a large pile of small scripts. A few of us who were willing to troubleshoot ourselves would use Bash, Fish, or another shell interactively. None of the libraries were set up for Bash/sh so it was difficult to write scripts that weren't for personal use. It was an April Fool's joke that we were moving to Bash and I was bummed. I spent some personal time making our libraries agnostic (a bulk of the code was Python, but environment stuff shelled out or inherited from the tcsh scripts).

I think it's worth focusing on Bash, but at least contrasting it with csh and pointing out the lineage and other options. Perhaps spending some time writing some scripts in sh since there is a large install base of outdated or missing Bash.

I have no idea what schools think about this. I generally prefer deep knowledge in a single language, but there is value in learning a bunch of languages so picking up yet another new language is trivial. When I've spent too much time in one specific language I've found it harder to switch around.

I preferred Zsh for a long time because it was much nicer to program in than Bash. But Bash has since then picked up all of the Zsh features I cared about and is installed by default most of the time so I switched.

I'm guessing the csh curriculum was just old. csh was developed as an improvement to sh (just like bash) that some circles coalesced around before everyone chose bash. I doubt it was that they saw everyone using today and said, fuck that, let's use csh.

My company still does intro lessons with ksh because it's set as the default shell on all of our servers.

Reply on news.ycombinator.com