Chris's Wiki :: blog/unix/WhyISwitchedToRc Commentshttps://utcc.utoronto.ca/~cks/space/blog/unix/WhyISwitchedToRc?atomcommentsDWiki2016-09-28T21:50:07ZRecent comments in Chris's Wiki :: blog/unix/WhyISwitchedToRc.From 193.158.187.135 on /blog/unix/WhyISwitchedToRctag:CSpace:blog/unix/WhyISwitchedToRc:f8803ed2bb2775ad72d15dc0fd2ee9f16d460eb9From 193.158.187.135<div class="wikitext"><p>I was considering using rc or es as an interactive shell and writing new shell scripts in. What exactly was bad about es compared to rc? From what I understand the original rc developer worked on es as well.</p>
</div>2016-09-28T21:50:07ZBy Chris Siebenmann on /blog/unix/WhyISwitchedToRctag:CSpace:blog/unix/WhyISwitchedToRc:894218d64e406fffd27fe36124066cd665db23f7Chris Siebenmann<div class="wikitext"><p>I'm reasonably familiar with es (I ran the original mailing list and
distribution site), but as far as I remember my reaction to it was that
it was a bit too much strangeness for not enough benefit for me. I might
have seen more benefit if I'd been writing substantial shell scripts in
rc, but I wasn't for various reasons; rc has mostly been an interactive
shell. I see it sort of as Scheme versus C, and I'm a C person.</p>
<p>(rc is generally much more pleasant for writing shell scripts in than
the old Bourne shell but it's also much less available, and much less
known by other people if I'm writing scripts I might want to share.)</p>
</div>2016-09-28T19:13:21ZFrom 193.158.187.135 on /blog/unix/WhyISwitchedToRctag:CSpace:blog/unix/WhyISwitchedToRc:6cda02bbda3bcf47d5b4704a77626b2e4736c259From 193.158.187.135<div class="wikitext"><p>Have you looked into the equally lightly maintained es shell? it's an improvement of rc from what I can tell. <a href="https://github.com/wryun/es-shell">https://github.com/wryun/es-shell</a></p>
</div>2016-09-28T15:34:03ZBy Chris Siebenmann on /blog/unix/WhyISwitchedToRctag:CSpace:blog/unix/WhyISwitchedToRc:a24e9387d6c286edab6e5db67ba7071d9acdebedChris Siebenmann<div class="wikitext"><p>I was lazy in the entry and used 'readline support' as a convenient
shorthand for command line editing in general. However it turns out that
I should have looked up the history of <code>tcsh</code> first, because <code>tcsh</code>
had command line editing from the very start; indeed, according to
<a href="https://en.wikipedia.org/wiki/Tcsh">the <code>tcsh</code> Wikipedia page</a>, that
was the major difference from <code>csh</code>.</p>
<p>(For some reason I had remembered <code>tcsh</code> as mostly being about fixing
various <code>csh</code> warts and bugs. This means that I was using command line
editing and filename completion way back in those days and was willing
to give it up when I shifted first to <code>ash</code> and then to <code>rc</code>. I'm not
sure I'd do that today, but then I don't use <code>9term</code> any more and I
think that filenames and so on are a longer today than they used to be.)</p>
</div>2016-09-28T14:56:00ZBy Opk on /blog/unix/WhyISwitchedToRctag:CSpace:blog/unix/WhyISwitchedToRc:29ec7dcb21a54947377597b0447b57898ef690a0Opk<div class="wikitext"><p>tcsh won't have had readline support in those days because it has never had readline support. It has it's own very decent line editor. Even if they wanted to use it, readline is GPL and not even LGPL.</p>
<p>At around the same time I made the opposite decision to you. My university computer science department pushed rc as the default shell and after a short while, I moved to tcsh and later zsh. Mainly for the completion rather than job control but my background before that was using 4DOS so I had already become accustomed to having completion. As you say, bash wasn't even a consideration in those days. It has only come to predominate due to the GNU stack as a whole being default on Linux.</p>
<p>In terms of saving disc reads for functions, and especially in light of shellshock, the ksh and zsh feature of autoloading functions works well.</p>
</div>2016-09-28T07:47:15Z